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

[Zoltan Somogyi]

On Tue, 17 May 2016 17:59:03 +1000, Mark Brown <mark at mercurylang.org> wrote:
> Granted, it's not as nasty as being able to change the operator
> precedence table mid-module. But there's some important cues that I'd
> like to be able to rely on, such as that the right operand of infix
> ':-' is a goal, or that the first operand of 'trace' is a list of
> trace paramaters, even though these may superficially resemble data
> terms. I don't think I can rely on that if there may be a pragma or
> import_module somewhere that changes the rules.
> 
> Part of the reason I support the changes you've been making is that
> restricting the language can on its own help readers of the code, over
> and above the error messages which benefit writers. The availability
> of this pragma undermines that advantage, even, I would argue, when it
> is not being used.

I agree on both points, but I am not the one who you must convince
on this point.

> > Yes, it does that. It also gives them significant work to do.
> > I would prefer to impose such work on Mercury users
> > only when it buys them something they are likely to value
> > more than better error messages for syntax errors
> > that may be rare in their experience.
> 
> Then why pester them at all?

I don't want to pester anyone. Adding the pragma would make the
error go away.

I also don't want to bother the people who know what they are doing.
I just want to nudge people who choose keywords as the names of things
without making a conscious choice to do so. Without something like this
pragma, I don't see how we can separate the two kinds of cases.
 
> Then I think we should revisit Peter's question of whether we can
> improve error messages another way. What if the parser did something
> like:
> 
>    if
>        Term = functor(atom(Name), ArgTerms, _) and
>        ( ArgTerms match the pattern we expect
>        for the construct whose top functor is Name or
>        Name is not defined )
>    then
>         consider Term to be that construct, possibly
>         generating an error message
>    else
>         consider Term to be call

Regardless of how desirable that proposal may be, it cannot be
implemented without huge pain, because the "possibly generating
an error message" is a task that belongs to the typechecker,
the rest of that code belongs to the parser, and the two cannot
be combined without huge pain.

Zoltan.