[m-dev.] getting type representation decisions from .int files

[Zoltan Somogyi]

2021-06-30 11:58 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
> You can commit and I'll try to review them post-commit. I don't want to
> block your progress, and reviewing the changes will take more than
> a quick glance.

Thanks for that review.

>> What is there to be gained
>> by allowing the subtype to add type parameters,
> 
> Type parameters that occur in the SUBTYPE part but not the SUPERTYPE
> part would have to be phantom types.
> 
>> or to permute any existing type parameters?
> 
> I think this question comes from an assumption that a type parameter
> in the supertype remains a type parameter in the subtype.

I was assuming that parameters of the subtype would *often* have corresponding
parameters in the supertype. I was not assuming that it *always* would be.

I am attaching a proposed diff to the reference manual, for review by both
Peter and Julien.

> That's not necessarily the case, as in:
> 
>     :- type non_empty_list_of_citrus =< list(citrus)
>         --->    [citrus | list(citrus)].
> 
>> And where is this restriction enforced?
>> I couldn't find anything related to this in check_subtype_defn in add_type.m.
> 
> It's checked in check_supertype_vars in parse_type_defn.m.

Is there some special reason why this check is not in add_type.m, with all
the other checks on subtype definitions? I would have thought that
having all the semantic checks for a given construct being in one place
is a good thing.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.refman
Type: application/x-research-info-systems
Size: 6429 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20210703/2ac210d1/attachment.bin>