[m-dev.] getting type representation decisions from .int files
zoltan.somogyi at runbox.com
Sat Jul 3 10:24:34 AEST 2021
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6429 bytes
Desc: not available
More information about the developers