What is a type error?

Chris Smith cdsmith at twu.net
Mon Jun 26 20:53:42 CEST 2006


Pascal Costanza <pc at p-cos.net> wrote:
> Chris Smith wrote:
> > Of course zero is not appropriate as a second argument to the division 
> > operator!  I can't possibly see how you could claim that it is.  The 
> > only reasonable statement worth making is that there doesn't exist a 
> > type system in widespread use that is capable of checking this.
> 
> ...and this is typically not even checked at the stage where type tags 
> are checked in dynamically-typed languages. Hence, it is not a type 
> error. (A type error is always what you define to be a type error within 
>   a given type system, right?)

Sure, it's not a type error for that language.

> Note, this example was in response to David's reply that my definition 
> turns every runtime error into a type error. That's not the case, and 
> that's all I want to say.

But your definition does do that.  Your definition of a type error was 
when a program attempts to invoke an operation on values that are not 
appropriate for this operation.  Clearly, in this example, the program 
is invoking an operation (division) on values that are not appropriate 
(zero for the second argument).  Hence, if your definition really is a 
definition, then this must qualify.

> > However, it sounds as 
> > if you're claiming that it wouldn't be possible for the type system to 
> > do this?
> 
> No. I only need an example where a certain error is not a type error in 
> _some_ language. I don't need to make a universal claim here.

Definitions are understood to be statements of the form "if and only 
if".  They assert that /everything/ that fits the definition is 
describable by the word, and /everything/ that doesn't is not 
describable by the word.  If that's not what you meant, then we are 
still in search of a definition.

If you want to make a statement instead of the sort you've implied 
above... namely that a type error is *any* error that's raised by a type 
system, then that's fine.  It certainly brings us closer to static 
types.  Now, though, the task is to define a type system without making 
a circular reference to types.  You've already rejected the statement 
that all runtime errors are type errors, because you specifically reject 
the division by zero case as a type error for most languages.  What is 
that distinction?

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation



More information about the Python-list mailing list