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

[Peter Wang]

On Sun, 08 May 2016 17:04:58 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Sun, 8 May 2016 15:11:16 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > Let me try to summarise it.  The compiler will reject the use of these
> > names as data-functors and compound data-terms:
> > 
> >     :           (still allowed as a data-functor)
> >     with_type
> >     @           (still allowed as a data-functor)
> >     ^           (still allowed as a data-functor)
> >     :=
> >     :-
> >     -->
> >     is
> 
> After this change, one-character names above are still allowed
> to be used with arity 0 because the lexer generates the same output
> when it sees e.g. @ as when it sees '@'. Programs must be able to
> use every character as a character constant. If it weren't for this,
> I would also want to disallow their use with arity 0 as well.
> 
> > Those names are not rejected as part of type definitions.  It is
> > possible to construct/deconstruct terms with those names through the
> > standard library, just not directly in Mercury code.
> 
> I would be happy to change that, and reject any attempt to use
> any operator or word that has a meaning in Mercury syntax as the
> name of a data constructor, or as the name of any other user-defined
> entity, such as type name, mode name, predicate name etc. This includes
> @, ^ and :.
> 
> Can people please vote: would you support or oppose such a change?

Note that Prince has a list of functions including

    :- func ('@') = unicode.
    :- func ('^') = unicode.
    :- func (':') = unicode.

They could be renamed, sure.

I don't know exactly which operators or words you had in mind.
Does it include '=' as used in comparison_result?  Or 'not', as in
bool.not?  Is the standard library going to be privileged?

> > My preference is to keep the definition as-is.  The relevant rules might
> > be stated simply as:
> > 
> >     Any name can be used as a non-compound data-term.
> >     Any name can be used as the top-level functor of a compound data-term,
> >     which can be any compound term that is not a special data-term.
> 
> And I would like to change both occurrences of "any name" above to
> "any name except a Mercury operator or keyword", and then you can
> delete the last third. I think that is even simpler. But more to the point,
> I think it would make programming easier. (See the next part below
> for the why.)

I thought you might.  I don't know exactly which names you mean, but
users need to be able to define +, not, xor, etc. so I assume it's not
everything in the operator table.

> 
> I am also wondering: if you want the above rule, then why did you
> not say anything for the several similar changes I made to the compiler
> in the last several months? For example, the one that prevented the
> use of inst names such as free/2 and clobbered/3, or the one that
> prevented the uses of e.g. else/2 outside if-then-elses?

I probably didn't pay much attention to those changes (one of them is
unread in my inbox).  Anyway, it takes way more energy to try to defend
a philosophical objection than to point out a technical flaw.  I might
only have objected this time because I misunderstood your change.

Another reason to keep quiet: you might get more than you bargained for ;)

> > I like that there are no exceptions about which names are allowed where.
> > Mercury doesn't have keywords and non-keywords so, while it would be
> > possible to explain why *these* names are excluded and not *those*,
> > it still feels arbitrary.
> 
> "feels arbitrary": does this mean that your objection is philosophical,
> and not practical? What I mean is: would your code  be affected?

The objections are philosophical.  It is always possible to update code
and move on.  I just liked the language as it was better.

Peter