[mercury-users] Operator precedence of =>

Lee Naish lee at cs.mu.OZ.AU
Wed Jan 27 12:16:16 AEDT 1999


In message <19990126142821.G21557 at cam.sri.com>Ralph Becket wrote:
>all_p_and_q(Xs) :-
>	all [X] list__member(X, Xs) => p(X), q(X).
>
>and lawks a lordy, all Hell broke loose within negated contexts.  A
>quick bit of parenthesization and we reduce to
>
>all_p_and_q(Xs) :-
>	all [X] (
>		list__member(X, Xs) =>
>			( p(X), q(X) )
>	).
>
>which solves the problem.  Now, I'm not sure about other people, but
>I'd find it more natural (not to say, more convenient) to have the
>following precedence order (from most to least tightly binding):
>
>	conjunction < implication < quantification
>
>rather than the current order

A bit of historical info:

I strongly suspect Mercury inherited its precedences from NU-Prolog,
which was influenced by John Lloyd and Rodney Topor's "Extended Prolog".
The first implementation of this (on top of MU-Prolog) used the most
commonly used convention in first order logic (implication < conjunction),
and that has stuck.  For NU-Prolog we had to do some fiddling to get the
precedence of the quantifiers reasonable (and it was still not entirely
satisfactory in the end).

A reasonable alternative is what Ralph suggests - it is more compatible
with Prolog if you think of -> as an implication operator.  One problem
with conjunction < quantification is that all [X] not p(Y,X) then needs
parentheses when used in a conjunction.  The NU-Prolog design was
influenced by the desire to avoid parentheses in this common case,
though the tradeoffs in Mercury are a bit because the different rule for
implicit quantification means explicit quantifiers are needed less.

A more general point is that, whatever syntax is chosen, it is desirable
for there to be a small set of rules for the programmer to remember for
laying out their programs, and these should be stated explicitly to people
learning the language.  Eg, for Prolog there is the rule "don't put
parentheses around conjunctions of literals but always put them around
disjunctions and conditionals".  Beginners have all sorts of problems
with Prolog syntax because this rule is often not stated.  Note that the
rule is not necessarily "convenient" (in the sense of minimising the
number of parentheses) or natural.  The ideal is simplicity without
being too inconvenient or too unnatural (abandoning operators entirely
seems too inconvenient).

	lee



More information about the users mailing list