[m-rev.] for review: better error messages for lambda exprs
zoltan.somogyi at runbox.com
Tue May 17 10:43:41 AEST 2016
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
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.
More information about the reviews