[m-rev.] for post-commit review: warn about bad coerce arities

[Julien Fischer]

On Wed, 29 May 2024 at 18:15, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On 2024-05-29 17:42 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> > On Tue, 28 May 2024 17:35:26 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >>
> >> On 2024-05-28 17:32 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> >> > No, the restrictions on type, inst and mode names don't go that far.
> >> > They stay within their own "categories".
> >>
> >> That is correct. However, that is also exactly what I am proposing
> >> to do with "coerce": that all its uses *in goals* should be for the
> >> purpose of type coercion.
> >
> > Presumably the same reasoning applies to other names that can appear
> > in goals as well.
>
> It does, and the compiler has been enforcing it for quite a while now.
> Nobody noticed when the compiler started disallowing using e.g. "if"
> as a predicate name, because nobody had the bad taste to *use* "if"
> as a predicate name in the first place.
>
> > I'm not convinced there are issues with "coerce", presumably "apply",
> > possibly "@" and ":" (no doubt more) that requires a blanket ban,
> > especially if we disregard arity. We have examples of three of those
> > as function names; we'd be going out of our way to not allow them.
>
> What are those three examples?
>
> > My main concern is a growing list of reserved names, with no recourse
> > but to rename.
>
> To me, "no recourse but to change the code to be less confusing"
> does not sound like a terrible fate, especially to the *coworkers*
> of the original code author :-)

I don't know what examples Peter has in mind, but the Zinc compiler
certainly has
symbols (functions and data constructors) named coerce. These are intended,
naturally enough, for dealing with the compilation of Zinc coercions.  (These
predate the addition of subtypes to Mercury.)

> When I taught compilers, my standard example for why keywords
> being reserved is a good idea is this piece of *legal* PL/I code:
>
>    IF THEN THEN THEN = ELSE ELSE ELSE = THEN;
>
> Of course, this is rather an extreme case, but it gets the point across.
> Less extreme cases cause less confusion, but they *do* cause some.

The problem is that you end up with the language sitting on names that
may be desirable
for specific application domains (coerce, event and trace spring to mind).

> Julien, want to cast a tiebreak vote?

I am inclined to agree with Peter in this case.

Julien.