What is a type error?

[Darren New]

Chris Smith wrote:
>         // Inside this block, a has type int{17..21} and b has type
>         // int{18..22}

No what happens if right here you code
   b := 16;

Does that again change the type of "b"? Or is that an illegal 
instruction, because "b" has the "local type" of (18..22)?

>         signContract(a); // error, because a might be 17
>         signContract(b); // no error, because even though the declared
>                          // type of b is int{14..22}, it has a local
>                          // type of int{18..22}.


If the former (i.e., if reassigning to "b" changes the "static type" of 
b, then the term you're looking for is not type, but "typestate".

In other words, this is the same sort of test that disallows using an 
unassigned variable in a value-returning expression.  When
   { int a; int b; b := a; }
returns a compile-time error because "a" is uninitialized at the 
assignment, that's not the "type" of a, but the typestate. Just FYI.

> Incidentally, I'm not saying that such a feature would be a good idea.  

It actually works quite well if the language takes advantage of it 
consistantly and allows you to designate your expected typestates and such.

-- 
   Darren New / San Diego, CA, USA (PST)
     This octopus isn't tasty. Too many
     tentacles, not enough chops.