[m-dev.] subtypes (was Re: [m-rev.] for review: don't allow nondefault mode functions in terms)

[Mark Brown]

On Fri, Dec 11, 2015 at 11:10 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
>> For construct/3, it would be sufficient to store one bit of
>> information with the type constructor, or perhaps with each du
>> functor, that indicates whether there are any constraints on the
>> arguments at all.
>
> Exactly what constraints are you thinking of? Type class constraints?
> The presence of higher order values?  The presence of higher order
> values other than standard mode functions? Some combination
> of the above?

Mode constraints on construction unifications, over and above the
constraints the mode system already imposes. In other words, if a du
type definition has one of these new types in it the bit will be set,
otherwise it won't.

Construct/3 must dynamically check that these constraints are
satisfied, as it does with the existing type information. If there are
no constraints in the type_desc, as is the case for all existing code,
then the constraints are trivially satisfied. Hence this is a minimal
check for safety.

Mark