[m-rev.] for review: subtypes

[Mark Brown]

On Tue, Jan 7, 2014 at 6:23 PM, Peter Wang <novalazy at gmail.com> wrote:
> On Tue, 7 Jan 2014 17:08:06 +1100, Mark Brown <mark at mercurylang.org> wrote:
>> > If I'm not mistaken, container types could not be abstract exported.
>>
>> That's right. In none of these examples could the data structure be
>> abstractly exported, since Mercury does not support abstract insts.
>> The workaround in parsing_utils.m would still be needed.
>>
>> In the first two versions, that roadblock would at least be more
>> obvious, since the insts are explicit.
>
> In the alternative design, is that because you mean to export 'first'
> and 'non_empty_cord(T)'?  If 'non_empty_cord(T)' is not exported, then
> the type 'cord(T)' can still be abstractly exported, right?

No, I don't think it can. At least, I'm not sure what would go in the
interface files.

If the inst information is not passed on to importing modules, then
they could indeed subvert the mode system using exactly the technique
that you mention below.

>
>> >> >
>> >> > construct would be even more complicated, no doubt.
>> >>
>> >> The types in type_desc currently provide access to type information
>> >> only, not inst information. I wasn't planning to change that at all,
>> >> even in the alternative design, so construct, etc, won't be affected.
>> >
>> > construct should not be able to subvert the type declaration, though.
>>
>> Can you give me an example of what you mean?
>
> Again in the alternative design, the compiler should reject any attempt
> to construct the term `list([])'.  But is there anything to stop you
> constructing it dynamically?
>
>     TypeDesc = type_of(BadCord),
>     find_functor(TypeDesc, "list", 1, Functor, _),
>     Univ = construct(TypeDesc, Functor, [univ([] : list(int))]),
>     univ_to_type(Univ, BadCord : cord(int)),

Right, I see what you mean. These attempts are ultimately mode errors
and should be caught by the mode system. (Unfortunately, it doesn't
always do that even now. The attached program is accepted by recent
ROTDs but segfaults when run.)

Cheers,
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mode_error.m
Type: application/octet-stream
Size: 758 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140107/6403f099/attachment.obj>