[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>:
> On Wed, 30 Jun 2021 09:08:33 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 

> 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.

Thank you.
 
>> Second, I don't understand this sentence in the reference manual:
>> 
>> Any variable that occurs in @var{supertype} must occur in @var{subtype}.
>> 
>> Is it talking about the each type constructor's parameters, or about
>> all the type vars in each type's definition? The wording implies
>> the latter,
> 
> It is the latter. The restriction is that there cannot be free variables
> in the supertype part of the subtype definition.

I was confused by the fact that the quoted sentence was not
restricted to universally quantified variables.

> We should of course improve the wording
> since you found it confusing.

I will have a go at proposing such wording tonight.

>> 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.

OK, I get that, and will document that.

>> 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.
> That's not necessarily the case, as in:
> 
>     :- type non_empty_list_of_citrus =< list(citrus)
>         --->    [citrus | list(citrus)].

I don't see how that is an example of permuting type parameter vars,
since in that case, neither non_empty_list_of_citrus nor list(citrus)
has any type parameter vars.

>> 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.

Thanks for that; I will have a look.

Zoltan.