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

[Julien Fischer]

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 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.

Julien.