[m-rev.] for review: better error messages for lambda exprs
zoltan.somogyi at runbox.com
Wed May 11 23:37:07 AEST 2016
On Mon, 9 May 2016 15:11:40 +1000, Peter Wang <novalazy at gmail.com> wrote:
> Note that Prince has a list of functions including
> :- func ('@') = unicode.
> :- func ('^') = unicode.
> :- func (':') = unicode.
> They could be renamed, sure.
It seems that most people prefer my approach to reporting these
kinds of syntax errors to yours, so I will be committing my change.
However, I don't want to cause unnecessary problems, so I will wait
until you have renamed those functions. Please tell me when you have
We should probably give a similar warning on mercury-users,
but I want to decide on what to say *after* monday (see below).
> I don't know exactly which operators or words you had in mind.
Good point. I will make up a list for discussion.
> Does it include '=' as used in comparison_result? Or 'not', as in
> bool.not? Is the standard library going to be privileged?
That is the key question. My instinct is to try to reserve every word
or operator that would be used as a literal in a BNF grammar for Mercury
(if the Mercury parser were based on BNF), and to make exceptions
to this only as/when required by backward compatibility. Those two
would have to be exceptions, at least for now; there may be others.
We can discuss the details (e.g. can a module not named "bool" define
a predicate named "not"? can you use "not" as a type name?) in person
on monday. (My own preferred answers are "no" and "no", btw.)
More information about the reviews