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

[Zoltan Somogyi]

On Mon, 16 May 2016 20:16:58 +1000, Paul Bone <paul at bone.id.au> wrote:
> 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.

I like this. A further advantage you did not list is that it tells people who
unintentially name things after keywords that their choice has consequences
for later error messages; they can then add the pragma or not, as they choose.
(The error message that tells them that should mention the pragma, of course.)

We could decide any of several meanings of such a pragma.

(a) The presence of this pragma (which may be named e.g. allow_reserved_names)
could allow the use of any reserved name in the definition of any kind
of entity (inst, mode, type, function symbol, field, func, pred, class, mutable etc)
in the module, regardless of where the pragma appears.

(b) The pragma could list the kinds of entities to which it applies.

(c) The pragma could list the "reserved" names to which it applies.

(d) The pragma could list the exact list of entities to which it applies,
e.g. the predicate "not", the function symbol "=", etc.

I would vote for (d).

There is also an independent variable: should we require that
if any affected entities are in the module interface, then the pragma
should be there too? I don't think this is useful for (d), but it may be
for (a) and (b); it is probably a wash for (c).

BTW, since this pragma can work only if it is processed before ALL
the definitions whose processing it affects, I don't think it could have
been reasonably implemented with the old flat item list representation
of the parse tree, but with the structured replacement I implemented
last year, it shouldn't be a problem.

Zoltan.