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

[Zoltan Somogyi]

On Fri, 31 Jul 2026 17:19:34 +1000, Peter Wang <novalazy at gmail.com> wrote:

> On Thu, 30 Jul 2026 23:12:16 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > 
> > 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?
> 
> If I'm not mistaken, we can find the symmetric pairs close to where they
> are generated (in are_actual_param_type_pair_as_related_as_needed),

Yes, we can, but I don't think we should. Mostly because it is simpler
if each of typecheck_coerce.m and typecheck_errors.m has a single job:
finding errors, and reporting those errors respectively. Doing part of the job
of reporting errors in typecheck_coerce.m would go against that.

Also, doing the job in are_actual_param_type_pair_as_related_as_needed
would not be simpler than doing it in typecheck_errors.m, because
even are_actual_param_type_pair_as_related_as_needed has to search
two list of coerce_fails to find the symmetric matches.

> and the error message could say "Neither X nor Y is a subtype of the
> other", right?

That can happen regardless of where we "fuse" the two coerce_fails.
I intend to work on that next.

Zoltan.