Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!socrates.umd.edu!socrates!rockwell From: rockwell@socrates.umd.edu (Raul Rockwell) Newsgroups: comp.lang.misc Subject: Re: Run-time Type Errors in Smalltalk Message-ID: Date: 22 May 91 03:38:48 GMT References: <1991May20.172441.780@csc.canterbury.ac.nz> <1991May21.094937.25573@jyu.fi> Sender: rockwell@socrates.umd.edu (Raul Rockwell) Organization: Traveller Lines: 61 In-Reply-To: sakkinen@jyu.fi's message of 21 May 91 09: 49:37 GMT Michael Chisnall: > I think that a distinction that it may be useful to draw here > is between declarative languages (e.g. prolog, ML, hope, > miranda, smalltalk) which have a highly modular structure, and > non-declarative languages (such as pascal, fortran, cobol, ada) Markku Sakkinen: BTW, Smalltalk declarative?! Prolog has a modular structure?! heh. In the smalltalk group you've got languages which can declare data to be some type. In the pascal group you've got languages where you declare variables to be some type and data is typed as a side effect and you must handle type information with control flow (with exceptions for language intrinsics). The above grouping doesn't bear too close examination however... Markku Sakkinen: it looks like a silly statement (has anybody really made it?) that having to _declare_ the types of variables would make a language _less_ declarative. Well, the idea is that you can't declare the type of a piece of data, and must compensate by using some other mechanism to keep track of this state information. Me: >Am I the only one interested in pointing out that an infinite loop >is a type error? Markku Sakkinen: So it seems: you have probably insisted on that some 10 times during the last few months without getting many supporters. Most people evidently feel (like myself) that lumping too much into the concept 'type error' would make it too general to be interestingly different from 'error'. Well, in the context of turing machines, the definition of a type error is a combination of an algorithm and data which causes an infinite loop. But you're right, infinite loops are too general for them all to be called type errors. > Consider a recent bug I encountered: ... What is the connection of this programming mistake with _type_ errors? And how does it confirm your opinion that "testing is the only real good way"? Not "only real good way" but still essential. Essential does not mean that other techniques are not useful. About the bug: (1) it appeared as an infinite loop which occurred only for certain input values. (2) it is possible to write that particular algorithm (a string matching problem) without using loops. (3) in C, I had to represent some of the information as program state and write loops, so this was a data representation problem. I suppose I'm coming across as rather unreal, but I can't help it :-) I rarely use loops or conditional expressions in my own code because I rarely need to. Control flow is just another way to represent data. Raul Rockwell