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

[Zoltan Somogyi]

For review by Peter.

I am requesting feedback on three issues specifically,
and not just from Peter.

One issue is that the additional info we include in the diagnostic
for one new coerce_fail has two quite different versions, with one
commented out. Which approach do you prefer?

The second issue is whether coerce diagnostics should refer
to type variables by number, as they have done before this,
or by name, as my new additions do. This means that one
diagnostics now looks like this:

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.

It is clear that we should consistently use either names or numbers,
but which? I would prefer names, even though the source of those names
is the declaration of the type_ctor involved, not the names used for type
variables in the predicate in which the error occurs.

The third issue is module qualification. We now have this diagnostic:

coerce_type_error.m:045: In clause for predicate `bad_unrelated'/2:
coerce_type_error.m:045:   error: cannot coerce `X' from
coerce_type_error.m:045:   `coerce_type_error.orange_non_fruit' to
coerce_type_error.m:045:   `coerce_type_error.citrus'.
coerce_type_error.m:045:   The base type constructor of the coerce-from type is
coerce_type_error.m:045:   `orange_non_fruit'/0, while for the coerce-to type
coerce_type_error.m:045:   it is `fruit'/0.

The initial part includes module qualification, the final part does not.

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?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.cfr
Type: application/octet-stream
Size: 705 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260726/c21c76ec/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.cfr
Type: application/octet-stream
Size: 27622 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260726/c21c76ec/attachment-0003.obj>