David Hopwood <[EMAIL PROTECTED]> wrote: > Typical programming languages have many kinds of semantic error that can occur > at run-time: null references, array index out of bounds, assertion failures, > failed casts, "message not understood", ArrayStoreExceptions in Java, > arithmetic overflow, divide by zero, etc. > > Conventionally, some of these errors are called "type errors" and some are > not. But there seems to be little rhyme or reason to this categorization, as > far as I can see. If in a particular language, both array index bounds errors > and "message not understood" can occur at run-time, then there's no objective > reason to call one a type error and the other not. Both *could* potentially > be caught by a type-based analysis in some cases, and both *are not* caught > by such an analysis in that language.
Incidentally, yes! Filtering out the terminology stuff [as hard as this may be to believe on USENET where half the world seems to be trolls, I really was not so aware when I originally posted of how some communities use terminology and where the motivations come from], this was my original point. In the static sense, there is no such thing as a type error; only an error that's caught by a type system. I don't know if the same can be said of dynamic types. Some people here seem to be saying that there is a universal concept of "type error" in dynamic typing, but I've still yet to see a good precise definition (nor a good precise definition of dynamic typing at all). In either case it doesn't make sense, then, to compare how static type systems handle type errors versus how dynamic systems handle type errors. That's akin to asking how comparing how much many courses are offered at a five star restaurant versus how many courses are offered by the local university. (Yes, that's an exaggeration, of course. The word "type" in the static/dynamic typing world at least has a closer to common root.) > A more consistent terminology would reserve "type error" for errors that > occur when a typechecking/inference algorithm fails, or when an explicit > type coercion or typecheck fails. I am concerned as to whether that actually would turn out to have any meaning. If we are considering array length bounds checking by type systems (and just to confuse ourselves, by both static and dynamic type systems), then is the error condition that gets raised by the dynamic system a type error? Certainly, if the system keeps track of the fact that this is an array of length 5, and uses that information to complain when someone tries to treat the array as a different type (such as an array of length >= 7, for example), certainly that's a type error, right? Does the reference to the seventh index constitute an "explicit" type coercion? I don't know. It seems pretty explicit to me, but I suspect some may not agree. The same thing would certainly be a type error in a static system, if indeed the static system solved the array bounds problem at all. While this effort to salvage the term "type error" in dynamic languages is interesting, I fear it will fail. Either we'll all have to admit that "type" in the dynamic sense is a psychological concept with no precise technical definition (as was at least hinted by Anton's post earlier, whether intentionally or not) or someone is going to have to propose a technical meaning that makes sense, independently of what is meant by "type" in a static system. > In the terminology I'm suggesting, the object has no type in this language > (assuming we're talking about a Smalltalk-like language without any type > system > extensions). I suspect you'll see the Smalltalk version of the objections raised in response to my post earlier. In other words, whatever terminology you think is consistent, you'll probably have a tough time convincing Smalltalkers to stop saying "type" if they did before. If you exclude "message not understood" as a type error, then I think you're excluding type errors from Smalltalk entirely, which contradicts the psychological understanding again. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list