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

[Zoltan Somogyi]

On Tue, 17 May 2016 09:26:11 +1000, Mark Brown <mark at mercurylang.org> wrote:
> Here's my views on the proposed keywords.

What I posted was a list of the words that the parser currently looks for.
It was intended as a basis for discussion, NOT as a proposal.
 
> > +    ; Name = "equality"             % type defn
> > +    ; Name = "comparison"           % type defn
> > +    ; Name = "representation"       % type defn
> > +    ; Name = "constraint_store"     % type defn
> > +    ; Name = "direct_arg"           % type defn
> > +    ; Name = "type_is_abstract_enum"            % type defn
> > +    ; Name = "type_is_abstract_noncanonical"    % type defn
> 
> I don't agree with these. They only have significance after the
> "where" keyword has been seen, and most likely will also involve "is".
> Can you give an example where we can't produce a good error?

I haven't tried. (See above.)
 
> > +    ; Name = "source_file"          % pragma decl
> ...
> > +    ; Name = "foreign_name"         % mutable decl
> 
> I don't agree with reserving any of these, as they only have
> significance in specific places after a "pragma" or "mutable" keyword
> has been seen. Can you give an example where we can't produce a good
> error?

Again, I haven't tried.

> > +    ; Name = "atomic"               % goal
> > +    ; Name = "or_else"              % goal
> > +    ; Name = "outer"                % goal
> > +    ; Name = "inner"                % goal
> 
> A bit harsh - these are not openly documented. As above, if "atomic"
> is reserved I don't think "inner" and "outer" need to be. I don't know
> what "or_else" is.
> 
> > +    ; Name = "vars"                 % goal
> 
> I don't know what "vars" is either.

or_else and vars are both part of the syntax of atomic goals.

> Note that I'm happy to prohibit all of these names in the compiler
> coding standard.

That's what I am working towards, since that is a good idea
independent of what atoms we reserve.

Zoltan.