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
--
http://mail.python.org/mailman/listinfo/python-list
