[m-rev.] for review: subtypes

[Julien Fischer]

Hi,

On Thu, 9 Jan 2014, Peter Wang wrote:

>> To put things another way, in the alternative design a type can be
>> turned into a (type, inst) pair. We can't abstractly export that
>> because the Mercury implementation doesn't support abstractly exported
>> insts yet.
>>
>> It's worth pointing out that the design I chose is conservative, in
>> the sense that it reports an error in these cases. So in future, if
>> abstractly exported insts are implemented, we would be able to move to
>> the alternative design without breaking any existing programs.
>>>
>>> I was imagining that importing modules would still work with 'ground'
>>> cord(T) values, so the module interface remains unchanged.  Where the
>>> compiler can see a type declaration referring to subtypes, it can use
>>> that information to infer more precise insts for functor arguments,
>>> e.g. deconstruction
>>>
>>>     % C is ground
>>>     C = cord.list(L)
>>>     % C is bound(list(bound([ground | ground])))
>>>     % L is bound([ground | ground])
>>
>> I think it is just constructing dynamically that is a problem.
>
> The compiler could generate a function for each subtype which returns
> true if a value fits that subtype, then we extend typeinfos to contain
> pointers to such functions.  Construct could then check that its
> arguments have the expected subtypes, otherwise fail.

If the arguments don't have the expected subtypes there should be a mode
error (as mentioned elsewhere in this thread) -- I know in many cases
there's not at the moment, but that's a problem (or more likely, several
problems) with the mode checker.

I don't think extending the RTTI to deal with this is the right way of
going about it.

Cheers,
Julien.