[m-rev.] for review: compare du types separately

[Zoltan Somogyi]

On Tue, 28 Jul 2026 12:33:15 +1000, Peter Wang <novalazy at gmail.com> wrote:

> On Mon, 27 Jul 2026 13:34:12 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > 
> > 
> > On Mon, 27 Jul 2026 15:41:24 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > > On Mon, 27 Jul 2026 00:34:29 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > > --- a/tests/invalid/coerce_type_error.err_exp
> > > > +++ b/tests/invalid/coerce_type_error.err_exp
> > > > @@ -26,3 +26,10 @@ coerce_type_error.m:118:   error: cannot coerce `X' from
> > > >  coerce_type_error.m:118:   `coerce_type_error.wrap_abs(coerce_type_error.citrus)'
> > > >  coerce_type_error.m:118:   to
> > > >  coerce_type_error.m:118:   `coerce_type_error.wrap_abs(coerce_type_error.fruit)'.
> > > > +coerce_type_error.m:125: In clause for predicate `non_subtypes'/2:
> > > > +coerce_type_error.m:125:   error: cannot coerce `Fruits' from
> > > > +coerce_type_error.m:125:   `list.list(coerce_type_error.fruit)' to
> > > > +coerce_type_error.m:125:   `list.list(coerce_type_error.orange_non_fruit)'.
> > > > +coerce_type_error.m:125:   `coerce_type_error.fruit'/0 is not a subtype.
> > > > +coerce_type_error.m:125:   `coerce_type_error.orange_non_fruit'/0 is not a
> > > > +coerce_type_error.m:125:   subtype.
> > > 
> > > I think the last two sentences could mislead as to why the coercion is
> > > invalid. Ideally, it would say something like: Neither `fruit' nor
> > > `orange_non_fruit' is a subtype of the other.
> > 
> > I see two issues here.
> > 
> > The less important one is that at the moment, each "X is not a subtype"
> > is a separate coerce_fail that is discovered independently, so replacing two of those
> > with one message will require post-processing the list of coerce_fails.
> > Since we already do this (in another form), this is a minor annoyance.
> > 
> > The more significant issue is that "fruit is not a subtype" is a stronger statement
> > than "fruit is not a subtype of orange_non_fruit", and therefore it gives
> > more info to the user. I happen to think that extra info may be useful,
> > at least sometimes. If you don't think so, can you please tell me your reason.
> 
> The issue is that neither "fruit is not a subtype" or "orange_non_fruit
> is not a subtype" are, by themselves, the reason for the coercion to be
> invalid. But since the statements follow the error message, a reader
> may be misled into thinking "list(T) can only be coerced when T is a
> subtype".

I agree with your point: neither diagnostic is by itself sufficient for
the coerce op to fail. However, I also think that we should say *why*
the conversion in each direction won't work. The diagnostic above
does not do that, but the diagnostics generated by the compiler
with the diff I posted an hour or two ago DO give such details,
which differ between the two directions.

At the moment, the only way I can see to meet both those objectives
at the same time is to

- include both the from-type and the to-type in the coerce_fails
  that report such problems;

- looking for symmetric pairs of such coerce_fails, and when found,
  wrapping them up in a larger coerce_fail that contains both originals,

- printing both wrapped coerce_fails *after* a prelude that says
  something to the effect of "the real error is one of these two;
  I cannot figure out which one it is; that is up to you".
  Not in exactly those words, of course :-)

Can you think of a better approach?

Zoltan.