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

[Peter Wang]

On Fri, 06 May 2016 16:53:02 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > Hi Zoltan,
> > 
> > I object to the restriction.
> 
> Is this objection philosophical or practical? And to which parts
> of the change? The parts for lambda expressions, the parts for
> the ^, :=, : or @ operators, or all of them?

Sorry, I had misunderstood the extent of the change.

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

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.

A reminder of the terminology for myself and everyone reading:

    A data-term is either a variable, a data-functor, or a special
    data-term.  A special data-term is a conditional expression, a record
    syntax expression, a unification expression, a lambda expression, a
    higher-order function application, or an explicit type qualification.

    A data-functor is an integer, a float, a string, a character literal
    (any single-character name), a name, an implementation-defined literal,
    or a compound data-term.

    A compound data-term is a compound term which does not match the
    form of a special data-term, and whose arguments are data-terms.

My preference is to keep the definition as-is.  The relevant rules might
be stated simply as:

    Any name can be used as a non-compound data-term.
    Any name can be used as the top-level functor of a compound data-term,
    which can be any compound term that is not a special data-term.

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.

Can we improve error messages another way, like generating special error
messages if there is a type failure involving the names above?

Peter