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

[Paul Bone]

On Wed, May 11, 2016 at 09:44:28PM +1000, Julien Fischer wrote:
> 
> Hi Paul,
> 
> > On Wed, May 11, 2016 at 12:38:48PM +1000, Mark Brown wrote:
> > > On Wed, May 11, 2016 at 12:11 PM, Paul Bone <paul at bone.id.au> wrote:
> > > > Philosophically I support making Mercury easier to use, especially for new
> > > > developers.
> > > 
> > > I can't tell what you mean by "easier to use". Do you mean that if the
> > > set of legal programs is restricted, the language is harder to use?
> > 
> > If the compiler tells the developer more directly what is wrong with their
> > program, then the compiler is easier to use.  Both Zoltan and Peter's
> > proposals offer this.
> 
> No, with Zoltan's approach the compiler will tell the developer directly
> (i.e exactly) what is wrong with the program *without* generating a
> bunch of spurious errors along the way.

I must have been unclear because I wasn't expecting these replies.  I only
meant to say that both proposals aim to make the compiler easier to use
through better error messages.  Did I say something misleading, where?

(I'm asking because I'm concerned that I'm not communicating as clearly as I
could be, and would like to improve that for the future.)

> > > > I support the change, I would also be happy with Peter's alternative of
> > > > providing a hint to developers in the error messages involving these
> > > > symbols.
> > > 
> > > Can you give an example of what the hints would look like?
> > 
> > IT is Peter's suggestion, so I'm just guessing what he meant.
> > 
> > If the compiler creates a type error for a term involving a :- which is not
> > a lambda expression, then in addition to the usual type error the compiler
> > could print something like "Perhaps this is a malformed lambda expression."
> > to tell the programmer why the compiler got confused.
> 
> That's essentially the "blood splatter" approach Zoltan was referring
> to.  Given what the design goals of the Mercury language are I would
> prefer to trade some regularity of the language (i.e. not being able to
> use keywords to name various user-defined entities) for more precise
> reporting of syntax errors.

Yes.  I said I'd be happy with either solution (both solutions make Mercury
easier to use.)  I also meant to imply that I preferred Zoltan's solution,
but would also be happy with Peter's (it's still an improvement).


-- 
Paul Bone