[m-rev.] for review: expand the class of allowed coercions

[Zoltan Somogyi]

On Fri, 31 Jul 2026 16:18:42 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > When comparing the type of an argument of a data constructor
> > between the from-type and the to-type, we used to regard any appearance
> > of any type_ctor other than the one on the left-hand-side of the
> > type definition as requiring any type variable appearing in the type
> > as having to be invariant.
> > 
> > This prevented coercions from e.g. one_or_more(err_spec) to
> > one_or_more(diag_spec) despite err_spec being a subtype of diag_spec,
> > because this rule applied to the  appearance of list(T) in the type of
> > the second arg of the one_or_more data constructor.
> > 
> > Fix this situation by changing the code that did to allow it to
> > test, while gathering the invariant type parameters of the one_or_more/1
> > type_ctor, to invoke itself recursively to compute the set of invariant
> > type parameters of list/1 as well. In general, we can now look
> > arbitrarily deep into type structures, subject to some limitations.
> > 
> > - The first limitation is that we keep a stack of the type_ctors
> >   whose sets of invariant type params is being computed, and use it
> >   to return a conservative approximation of the actual result
> >   instead of descending into infinite recursion.
> > 
> > - The second is that we do not keep track of any substitutions
> >   of any type parameters. This means that for any type_ctor
> >   other than the one at the top level, all we care about is
> >   whether it may have any invariant type params; if it may,
> >   then we treat *all* its type params as having to be invariant.
> 
> Please update the reference manual to reflect the rules.

I will do so in a separate diff, to allow for easier review.

> > +    % The set of type_ctors for which we know whether they have any
> > +    % type parameters which must be invariant.
> > +    %
> > +    % XXX A better name than known_type_ctors would be nice.
> > +    % Maybe known_invariant_tparam_type_ctors, but it is kind of long.
> > +    %
> > +:- type known_type_ctors == map(type_ctor, invariant_tvars).
> > +
> > +:- func init_known_type_ctors = known_type_ctors.
> > +
> > +init_known_type_ctors = map.init.
> > +
> 
> type_ctor_invariant_tvars_map or invariant_tvars_map?
> Not very short, but more descriptive.

I went with invariant_tparams_map.

> You should update the comments in coerce_typecheck_eqv.m

I updated both the type names and the comments.

Thanks for the review.

Zoltan.