[m-rev.] for post-commit review: report on more kinds of coerce_fails

[Zoltan Somogyi]

On Mon, 27 Jul 2026 15:13:37 +1000, Peter Wang <novalazy at gmail.com> wrote:
> I think that could lead to confusion when there are same-named type
> variables in the predicate, which doesn't seem unlikely at all.
> On the whole, I would stick with the numbers for consistency
> with other error messages.

The committed version of this diff uses numbers.

> > I can see three possible approaches.
> > 
> > - never use module qualification
> > - always use module qualification
> > - use module qualification only if any module qualification differs
> >   between the from-type and the to-type. (Unlike a type_ctor, a full type
> >   may contain more than one sym_name.)
> > 
> > I thin the third option is best in balancing the two concerns of
> > 
> > - presenting information when it can be helpful
> > - not presenting information when it is not useful, but is only clutter.
> > 
> > What do you think?
> 
> That sounds okay.

I will do this soon.

>     You can only coerce between discriminated union types that have the
>     same base type constructor. This expression attempts to convert
>     [coerce] a value from a type with base type constructor X to a type
>     with base type constructor Y.

I think that would work, but only if the readers know what a base type is,
which unfortunately we cannot assume. If we use this wording, we will
need to add either a verbose-only, or always-printed, component that
provides that definition.

> >  coerce_type_error.m:070: In clause for predicate `bad_phantom'/2:
> >  coerce_type_error.m:070:   error: cannot coerce `X' from
> >  coerce_type_error.m:070:   `coerce_type_error.phantom(int)' to
> >  coerce_type_error.m:070:   `coerce_type_error.phantom(float)'.
> > +coerce_type_error.m:070:   Builtin types such as float and int cannot be either
> > +coerce_type_error.m:070:   coerced from, or coerced to.
> >  coerce_type_error.m:091: In clause for predicate `bad_higher_order'/2:
> >  coerce_type_error.m:091:   error: cannot coerce `X' from
> >  coerce_type_error.m:091:   `coerce_type_error.wrap_ho(coerce_type_error.citrus)'
> 
> Hmm, while it is true that you cannot coerce builtin types,
> that isn't happening in this case.

Whether it is happening or not depends on what you consider part of
the coerce operation. In this case, the coerce attempts to convert from
phantom(int) to phantom(float), and I would consider that to include
an implicit sub-coerce, if you will, from int to float.

I have no idea which of these two views is more common among
the users of Mercury subtypes.

> Technically, a coercion from phantom(int) to phantom(float) would be
> sound, so we could allow it. We would need to introduce an exemption to
> the rule that requires type parameters to be equal or in a subtype
> relationship, if the type parameters are unused in the body of the base
> type constructor.

Agreed. However, until I see a real life example of coercion involving
a phantom type parameter, I have no way to form a reasoned judgement
of the issue of whether this would be a good idea or not.

> > diff --git a/tests/invalid/coerce_unify_tvars.err_exp b/tests/invalid/coerce_unify_tvars.err_exp
> > index 7e3294902..ef2d295c2 100644
> > --- a/tests/invalid/coerce_unify_tvars.err_exp
> > +++ b/tests/invalid/coerce_unify_tvars.err_exp
> > @@ -1,3 +1,5 @@
> >  coerce_unify_tvars.m:063: In clause for predicate `head_type_params'/2:
> >  coerce_unify_tvars.m:063:   error: cannot coerce `X' from `list.list(V_1)' to
> >  coerce_unify_tvars.m:063:   `list.list(V_2)'.
> > +coerce_unify_tvars.m:063:   Type variables such as T2 and T1 cannot be either
> > +coerce_unify_tvars.m:063:   coerced from, or coerced to.
> 
> Suggestion:
> 
>     The coercion is invalid because the unconstrained type variables V_1
>     and V_2 are not known to be equal or to have a subtype relationship.

How about this:

{An unconstrained type variable such as V_1, Unconstrained type variables
such as V_1 and V_2} cannot be either coerced from or coerced to, because
by definition, {it is,they are} not known to be either equal to any type, or to be
in a subtype relationship with any type.

Thanks for the review.

Zoltan.