Re: Ann: SWI-Prolog 7.1.0

On 27/11/2013, at 4:31 AM, Alan Baljeu wrote:

>>>     - Quoted atoms are no longer operators.
> 
>>> 
>>> 
>>> Like Haskell.  Good idea.
>> 
>> How is this like Haskell?
> 
> 
> Unless my memory fails me, parenthesized operators are not 
> operators, so you can do 
> foo 2 (+) 3

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

The claim was specifically that making *QUOTED* atoms not
act as operators was like Haskell, and it isn't.  To repeat,
Haskell uses backquoting for the *OPPOSITE* purpose, to
turn a lexeme that would otherwise be a plain variable into
something that IS an operator.

This change also creates horrible difficulties.
Right now, in ISO Prolog + Unicode, you can do something like

:- op(400, yfx, ('∩')).

set_expr(X ∩ Y, R) :- ...

and if this has to be transported through systems of unknown
Unicode support it can be mechanically converted to

:- op(400, yfx, ('\u2229')).

set_expr(X '\u2229' Y, R) :- ...

and when it arrives at a Unicode-capable system, it can be
used _as is_ or converted back to the original form with
*no* difference in semantics.  The conversion is about as
simple as it gets: copy each token verbatim _unless_ it is
an atom that is not a legal unquoted atom according to 
strict unextended ISO Prolog rules, in which case add
single quotation marks (plus maybe a space at each end
if necessary and \u-escape the non-standard characters).
This conversion does not have to know anything about the
*syntax* of Prolog, only the *lexical* structure.

This change breaks that.

And I for one have used operators such as
	X 'is included in' Y
which this change utterly prevents.  R supports this.
Example:

> "%is included in%" <- function (x, y) sum(x == y) > 0
> 1 %is included in% c(3,1,4)
[1] TRUE

Off-hand, I can't think of _any_ programming language
where quoting an operator makes it a non-operator.

Now in Haskell, the reason why (+) is not an operator
is subtle.

	( +y) = \x -> x+y
	(x+ ) = \y -> x+y
	( + ) = \x -> \y -> x+y

It's really an "invisible arguments are implicit lambda-abstraction"
rule, not a "switch off operator properties" rule.

> But thinking again, Where is '+' useful in SWI?  You never use 
> an isolated operator.
> +(2,3) works fine
> foo(2,+,3) also works.

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.)
Of course, the new quotes-change-things rule
doesn't help one iota with this:  if you aren't expecting
any problems you aren't going to quote any atoms that you
wouldn't have parenthesised.

F# uses (op) to switch off operator properties, not quoting.
(Given that (* opens comments, allowing (*) as a non-operator
reference to * required some care!)

Ada requires you to use operator names in strings when
defining (overloadings of) the built-in operators, but
I haven't been able to find anything in the LRM that
allows this in _mentions_ of such an operation.

Eiffel also requires you to quote an operator when _defining_
it, but has no notion of quoting or parenthesising an
operator to make it a value.  (If you want an operator as
a value you use an "agent expression".)

Off-hand, I can't think of any programming language I've used
enough to remember where quoting an operator makes it act like
a plain identifier in *uses*.

> 
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog