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

[Mark Brown]

On Tue, May 17, 2016 at 2:13 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Tue, 17 May 2016 13:26:40 +1000, Mark Brown <mark at mercurylang.org> wrote:
>> I don't. For one thing, you've already convinced me that the
>> flexibility of being able to use such symbols is of little value.
>
> To me, and to you. To people who already use such symbols,
> the answer is likely different, since it makes adapting to the
> effective change in the language when we in effect reserve
> some keywords is much easier.

That's reasonable; it's the same reason I want to minimise the number
of words being reserved. I doubt the feature will only be used
transitionally, though.

>> also don't like that I can be looking at a screenful of code while the
>> declarations that tell me how to parse what I'm looking at could be
>> thousands of lines away.
>
> That wouldn't happen. You would parse syntactically correct code
> exactly the same as now.

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.

>> How does it work with the module system? If you import a module with
>> this pragma do you have to declare the pragma yourself to use the
>> symbols?
>
> That depends on exactly how we decide the pragma should work.
> That is why I mentioned the question of imposing the requirement
> that if the entity with the reserved name is exported, the pragma
> must be exported too; then the importing module will get both,
> and can adapt accordingly.
>
>> Or do you lose good error messages?
>
> The point of the pragma is to change how strict the parser is.

I'm concerned how far the effect spreads.

>> That's not really an advantage, because prohibiting these names also
>> tells people that their choice has consequences.
>
> 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?

> And in some cases, the "them" is us. For example, replacing
> "=" as a function symbol in the comparison_result type would
> NOT be trivial. Given that it has been several years since I had
> a syntax error involving that function symbol, I would rather
> not impose that work on myself, or on anyone else in the team.

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

?

Mark