[m-rev.] for review: subtypes

[Mark Brown]

On Thu, Jan 9, 2014 at 5:31 PM, Peter Wang <novalazy at gmail.com> wrote:
> On Thu, 9 Jan 2014 16:35:27 +1100 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>> Hi,
>>
>> On Thu, 9 Jan 2014, Peter Wang wrote:
>>
> ...
>> >>
>> >> 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.
>
> Not if, as I hope, the use of subtypes for functor arguments can be kept
> internal to a module.

You mean it should not be checked statically?

>
> To reiterate the example, say cord.m uses subtypes internally but
> presents the same interface as before.  To an importing module, cord(T)
> is an abstract type and cord values are just 'ground'.  There, you could
> dynamically construct a cord value where arguments don't have the
> expected subtypes, and there would be no mode error because the value
> has inst 'ground' as expected.
>
> Right?

Correct. The error would be in cord.m, which is trying to implicitly
define an abstract inst. Mercury doesn't support these yet.

The workarounds are the same as are already used for insts (eg., in
parsing_utils.m). Really this issue doesn't have anything to do with
subtype declarations.

Cheers,
Mark.