What is a type error?

[Marshall]

Joachim Durchholz wrote:
> 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.

I'm not sure I understand. Could you elaborate?


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

Again I'm not entirely clear what this means. Are you talking
about pre/post conditions, or are you talking about having the
constraint language itself be something other than functional?


Marshall