[m-rev.] for review: better error messages for lambda exprs
novalazy at gmail.com
Mon May 9 15:11:40 AEST 2016
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.
More information about the reviews