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

[Zoltan Somogyi]

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 :-)

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.

Julien, want to cast a tiebreak vote?

Zoltan.