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

[Zoltan Somogyi]

> > @@ -8520,39 +8524,64 @@ coerce(@var{Term})
> >  The expression is type-correct if and only if
> >  @var{FromType} and @var{ToType} are both discriminated union types,
> >  and after replacing the principal type constructors with base types
> > + at c XXX This reads like a category error:
> > + at c you replace a type_ctor with another type_ctor,
> > + at c or a type_ctor with another type;
> > + at c you do not replace a type_ctor with a complete type.
> >  (@pxref{Subtypes})
> >  the two types have the same type constructor,
> >  and the arguments of the common type constructor
> >  satisfy the type parameter variance restrictions below.
> >  
> 
> You're right.
> 
>     The expression is type-correct if and only if
>     @var{FromType} and @var{ToType} are both discriminated union types
>     and, after replacing the principal type constructors
>     with their base type constructors,
>     the resulting types have the same principal type constructor,
>     and the arguments of that principal type constructor
>     satisfy the type parameter variance restrictions below.

I don't think that works, because "replacing the type constructors"
does not cover every change we want to describe. What we want here
is the same as what we want ...

> >  Let @var{FromType} expand out to @samp{base(S1, ..., Sn)}
> > + at c XXX In the subtype section, we use "expand" only in the sense of
> > + at c expanding out equivalence types. Here, we also include replacing each
> > + at c subtype with its supertype, using the head of the subtype's definition.
> > + at c Do we have a specific name for that operation?
> > + at c If not, *should* we give it a name?
> 
> Maybe "resolve to"?

... here.

I don't think "resolve to" works, because it already has another definition
(choosing which of several visible entities has the right type in e.g.
a specific call).

In the attached updated diff, I defined this operation, and gave it the name
"lift", as from subtype to supertype. Better names welcome; any link
to an existing name for this operation would be even more welcome,
since a standard name is better than a good name :-(

The diff proposes three new alternative ways to define the subtype relation,
all using this new operation. Can you guys please look at them, and report
your preferences among them?

> >  and @var{ToType} expand out to @samp{base(T1, ..., Tn)},
> >  where @samp{base(B1, ..., Bn)} is the common base type,
> >  and @var{Bi} is the i'th type parameter,
> >  which is bound to @var{Si} in @var{FromType}
> >  and @var{Ti} in @var{ToType}.
> > + at c XXX Wouldn't Fi be better notation than Si?
> > + at c Si would make sense if we talked about source types, but
> > + at c we call them about from-types.
> 
> S and T are pretty common for types, e.g.
> https://en.wikipedia.org/wiki/Subtyping

Ok, I will keep S.

> Also, subtyping relations are often written with a <: operator.
> We could do that as well.

We already use =<. The wikipedia page on subtyping lists that
as a common notation, alongside <:.

> > + at c XXX And wouldn't BPi be better notation than just Bi?
> > + at c It would clarify that BPi are type parameters, i.e. type variables,
> > + at c while the Si/Fi/Ti are complete types.
> >  
> 
> Perhaps, or BVi (for variable)?

Parameter is more specific than variable, since it says where it comes from.
That's why I prefer that notation.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.rm2
Type: application/octet-stream
Size: 9103 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260801/844623bf/attachment.obj>