What is a type error?

[Chris Smith]

Darren New <dnew at san.rr.com> wrote:
> 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)?

It arranges that the expression "b" after that line (barring further 
changes) has type int{16..16}, which would make the later call to 
signContract illegal.

> 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".

We're back into discussion terminology, then.  How fun.  Yes, the word 
"typestate" is used to describe this in a good bit of literature.  
Nevertheless, a good number of authors -- including all of them that I'm 
aware of in programming language type theory -- would agree that "type" 
is a perfectly fine word.

When I said b has a type of int{18..22}, I meant that the type that will 
be inferred for the expression "b" when it occurs inside this block as 
an rvalue will be int{18..22}.  The type of the variable didn't change, 
because variables don't *have* types.  Expressions (or, depending on 
your terminology preference, terms) have types.  An expression "b" that 
occurs after your assignment is a different expression from the one that 
occurs before your assignment, so it's entirely expected that in the 
general case, it may have a different type.

It's also the case (and I didn't really acknowledge this before) that 
the expression "b" when used as an lvalue has a different type, which is 
determined according to different rules.  As such, the assignment to b 
was not at all influenced by the new type that was arranged for the 
expression "b" as an rvalue.

(I'm using lvalue and rvalue intuitively; in practice, these would be 
assigned on a case-by-case basis along the lines of actual operators or 
language syntax.)

> In other words, this is the same sort of test that disallows using an 
> unassigned variable in a value-returning expression.

Yes, it is.

> 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.

If you wish to say "typestate" to mean this, be my guest.  It is also 
correct to say "type".

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

I'm not aware of a widely used language that implements stuff like this.  
Are you?

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