What is a type error?

[Chris Smith]

David Hopwood <david.nospam.hopwood at blueyonder.co.uk> 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