Re: Ann: SWI-Prolog 7.1.0

Richard O'Keefe:
>Yes but parenthesised operators are _already_ not operators
>in Prolog.  You can do foo((:-),(-->)) in ISO Prolog.

Just for clarity: In ISO Prolog foo(:-,-->). is valid canonical syntax
that can be read with any operator declarations present.
In DEC10 they had to be bracketed.  Therefore also
operator declarations like

:- op(1200,xfx,-->).

are valid ISO Prolog syntax and do not require neither round nor
square brackets.

>The claim was specifically that making *QUOTED* atoms not
>act as operators was like Haskell, and it isn't. ...

(Complete agreement on the quoting issue. I always expected them to be
used for writing if encoding was US-ASCII, in place of Latin-1 or
Unicode.)

>Actually, I _have_ used things like
>X = >, Y = <, Z = = , but always with the parentheses,
>even back in DEC-10 Prolog.
>
>I've never faced a problem with *known* built-in operators.
>You put parentheses around them and you're done.
>The problem is that _any_ atom could _become_ an operator,
>and at least canonical syntax needs to be safe from that.
>(Which it could be.  I still say f(-->) and f(:-,-->) should
>be legal: if the next token is , or | or ) or ] or } or
>end of clause an atom cannot be infix or prefix;
>if the previous token is , or |or ( or [ or { or end of
>clause an atom cannot be infix or postfix, so f(-->) is unambiguous.)

In ISO f(-->). and f(:-,-->). are legal.  Arguments of functional
notation as well as elements and the rest of a list, certainly also
{X} are all positions where bracketing is not needed atoms that are an
operator.  And all considered systems do it like that.  What requires
extra round brackets are comparison-like operators, all those with
Priority 700, and Specifier xfx,  So X = > . is invalid
X = (>) . is OK.

The next token rule you mention would reduce the need for round
brackets even further, but there are still situations left, where they
are needed.  Like ( X = (>) -> y ; n ).