What is a type error?

[Joachim Durchholz]

Chris Smith schrieb:
> For example, I wrote that example using variables of type int.  If we 
> were to suppose that we were actually working with variables of type 
> Person, then things get a little more complicated.  We would need a few 
> (infinite classes of) derived subtypes of Person that further constrain 
> the possible values for state.  For example, we'd need types like:
> 
>     Person{age:{18..29}}
> 
> But this starts to look bad, because we used to have this nice
> property called encapsulation.  To work around that, we'd need to
> make one of a few choices: [...] (c) invent some kind of generic
> constraint language so that constraints like this could be expressed
> without exposing field names. [...] Choice (c), though, looks a
> little daunting.

That's not too difficult.
Start with boolean expressions.
If you need to check everything statically, add enough constraints that 
they become decidable.
For the type language, you also need to add primitives for type 
checking, and if the language is stateful, you'll also want primitives 
for accessing earlier states (most notably at function entry).

> So I'll stop there.  The point is that while it is emphatically true 
> that this kind of stuff is possible, it is also very hard in Java.

No surprise: It's always very hard to retrofit an inference system to a 
language that wasn't designed for it.

This doesn't mean it can't be done. Adding genericity to Java was a 
pretty amazing feat.
(But I won't hold my breath for a constraint-style type system in Java 
anyway... *gg*)

Regards,
Jo