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

[Zoltan Somogyi]

On 2024-05-28 15:23 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> On Tue, 28 May 2024 13:14:58 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 
>> On 2024-05-28 12:56 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
>> > Technically, the user is allowed to name things 'coerce'.
>> > It's only 'coerce(Expr)' that is parsed as a type conversion expression.
>> 
>> Ok, but should we change that? I think we should.
>> 
> 
> I don't think so. That's how I think "special expressions" like 'apply'
> and 'coerce' ought to work. You can name e.g. functions apply/k or coerce/1,
> but you cannot call them by writing apply(X, Y) or coerce(X) since those
> mean something else. You just need to add parentheses or module qualify
> the function name, which seems fair enough, and in line with the rest of
> the language.

That is in line with how the rest of the language *used* to work.
We changed that over the last few years. We now prevent people
from defining types whose names are the same as a builtin type
or type constructor, and impose similar restrictions on inst and mode
names, and on the "keywords" the language uses for constructs
such as if-then-else. The discussion that started this is at
https://lists.mercurylang.org/archives/reviews/2015-August/018085.html.
Preventing "coerce" from being used for anything other than its
intended purpose would be consistent with all that.

Zoltan.