[m-rev.] for review: better error messages for lambda exprs

[Mark Brown]

Hi,

On Sun, May 8, 2016 at 5:04 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Sun, 8 May 2016 15:11:16 +1000, Peter Wang <novalazy at gmail.com> wrote:
>> Let me try to summarise it.  The compiler will reject the use of these
>> names as data-functors and compound data-terms:
>>
>>     :           (still allowed as a data-functor)
>>     with_type
>>     @           (still allowed as a data-functor)
>>     ^           (still allowed as a data-functor)
>>     :=
>>     :-
>>     -->
>>     is
>
> After this change, one-character names above are still allowed
> to be used with arity 0 because the lexer generates the same output
> when it sees e.g. @ as when it sees '@'. Programs must be able to
> use every character as a character constant. If it weren't for this,
> I would also want to disallow their use with arity 0 as well.
>
>> Those names are not rejected as part of type definitions.  It is
>> possible to construct/deconstruct terms with those names through the
>> standard library, just not directly in Mercury code.
>
> I would be happy to change that, and reject any attempt to use
> any operator or word that has a meaning in Mercury syntax as the
> name of a data constructor, or as the name of any other user-defined
> entity, such as type name, mode name, predicate name etc. This includes
> @, ^ and :.
>
> Can people please vote: would you support or oppose such a change?

I support reserving some words as keywords so they cannot be used as
names. Introducing a new keyword will always be
backwards-incompatible, and the keywords themselves limit what can be
done with io.write (which is not necessarily used to produce output
that will be consumed by io.read), but the benefit of better error
messages outweighs both of those things in my view.

The above list is too inclusive, however. The set of keywords should
be minimal: only enough to allow good error messages to be generated.

>> I like that there are no exceptions about which names are allowed where.
>> Mercury doesn't have keywords and non-keywords so, while it would be
>> possible to explain why *these* names are excluded and not *those*,
>> it still feels arbitrary.
>
> "feels arbitrary": does this mean that your objection is philosophical,
> and not practical? What I mean is: would your code  be affected?

Presumably new keywords may be added in future, so nobody can say for
sure their code will be unaffected.

Can we decide the complete set of names that we're going to reserve as
keywords in the near future? I would like to at least prohibit '::'/2
as a type name for the purposes of better errors in type declarations,
as I mentioned in an earlier post.

Mark