[m-rev.] for review: better error messages for lambda exprs
novalazy at gmail.com
Sun May 8 15:11:16 AEST 2016
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)
@ (still allowed as a data-functor)
^ (still allowed as a data-functor)
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?
More information about the reviews