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

Zoltan Somogyi zoltan.somogyi at runbox.com
Tue May 17 18:53:07 AEST 2016

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.


More information about the reviews mailing list