What is a type error?

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <pc at p-cos.net> writes:
> 
>> Chris Smith wrote:
>>
>>> 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.
>> What about this: You get a type error when the program attempts to
>> invoke an operation on values that are not appropriate for this
>> operation.
>>
>> Examples: adding numbers to strings; determining the string-length of
>> a number; applying a function on the wrong number of parameters;
>> applying a non-function; accessing an array with out-of-bound indexes;
>> etc.
> 
> Yes, the phrase "runtime type error" is actually a misnomer.  What one
> usually means by that is a situation where the operational semantics
> is "stuck", i.e., where the program, while not yet arrived at what's
> considered a "result", cannot make any progress because the current
> configuration does not match any of the rules of the dynamic
> semantics.
> 
> The reason why we call this a "type error" is that such situations are
> precisely the ones we want to statically rule out using sound static
> type systems.  So it is a "type error" in the sense that the static
> semantics was not strong enough to rule it out.
> 
>> Sending a message to an object that does not understand that message
>> is a type error. The "message not understood" machinery can be seen
>> either as a way to escape from this type error in case it occurs and
>> allow the program to still do something useful, or to actually remove
>> (some) potential type errors.
> 
> I disagree with this.  If the program keeps running in a defined way,
> then it is not what I would call a type error.  It definitely is not
> an error in the sense I described above.

If your view of a running program is that it is a "closed" system, then 
you're right. However, maybe there are several layers involved, so what 
appears to be a well-defined behavior from the outside may still be 
regarded as a type error internally.

A very obvious example of this is when you run a program in a debugger. 
There are two levels involved here: the program signals a type error, 
but that doesn't mean that the system as a whole is stuck. Instead, the 
debugger takes over and offers ways to deal with the type error. The 
very same program run without debugging support would indeed simply be 
stuck in the same situation.

So to rephrase: It depends on whether you use the "message not 
understood" machinery as a way to provide well-defined behavior for the 
base level, or rather as a means to deal with an otherwise unanticipated 
situation. In the former case it extends the language to remove certain 
type errors, in the latter case it provides a kind of debugging facility 
(and it indeed may be a good idea to deploy programs with debugging 
facilities, and not only use debugging tools at development time).

This is actually related to the notion of reflection, as coined by Brian 
C. Smith. In a reflective architecture, you distinguish between various 
interpreters, each of which interprets the program at the next level. A 
debugger is a program that runs at a different level than a base program 
that it debugs. However, the reflective system as a whole is "just" a 
single program seen from the outside (with one interpreter that runs the 
whole reflective tower). This distinction between the internal and the 
external view of a reflective system was already made by Brian Smith.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/