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

[Peter Wang]

On Tue, 28 May 2024 16:35:08 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 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.

No, the restrictions on type, inst and mode names don't go that far.
They stay within their own "categories".

Really, we still allow a lot:

    :- type allowed_types
	--->	int(int)
	;	float(float).

    :- type pred_or_func
	--->	(pred)
	;	(func).

    :- func (:) = unicode.
    :- func (@) = unicode.

    :- pred call(expr, expr).
    :- func apply(expr, expr) = expr.

and so on.

Peter