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

Paul Bone paul at bone.id.au
Mon May 16 20:16:58 AEST 2016

On Wed, May 11, 2016 at 11:37:07PM +1000, Zoltan Somogyi wrote:
> On Mon, 9 May 2016 15:11:40 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > 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.)

As we went to the train station, Peter and I were talking about this and it
made me think of an alternative.  Rather than making standard library
modules privileged (assuming we want to do that), we can introduce a pragma
to say "I want to use fancy symbols in this module" then people writing such
modules, including standard library modules, can declare that pragma
knowing that they may get less-friendly error messages.  This makes such
symbols available to user's programs and still enables the vast majority of
code to be compiled with friendlier error messages.

Paul Bone

More information about the reviews mailing list