dave8@and.cs.liv.ac.uk (02/23/91)
Re. the conditional, ->/2. Is the following a bug or a feature? If the following is entered during a consult/1 ... a( X ) :- ( true -> X = 1 ) ; X = 2 . then, when it is listed, it appears as a( X ) :- ( true -> X = 1 ; X = 2 ) . or a( X ) :- true -> X = 1 ; X = 2 . depending on which Prolog you run ... and, when it is executed, you only get a single solution: X = 1. I would have thought that this was a bug, but is it? It occurs with both C-Prolog 1.5a and POPLOG Prolog version 11. However, if you enter (the workaround) (I did want to use code like the above but obviously replacing "true" with some predicate) ... b( X ) :- ( true -> X = 1 ; fail ) ; X = 2 . then, when it is listed, it appears as the above, or the above plus a pair of extra brackets around the body ... and, when it is executed, both solutions are given (on backtracking) ( X = 1, then, X = 2 ) (as expected). Is this a parser problem or not? If so, it is a problem with a number of existing parsers. Dave Sherratt. Now probably ads@uk.ac.liv.cs
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (02/26/91)
In article <1991Feb22.172635.16587@and.cs.liv.ac.uk>, dave8@and.cs.liv.ac.uk writes: > If the following is entered during a consult/1 ... [*] > a( X ) :- ( true -> X = 1 ) ; X = 2 . > then, when it is listed, it appears as [a] > a( X ) :- ( true -> X = 1 ; X = 2 ) . > or [b] > a( X ) :- true -> X = 1 ; X = 2 . Stop and _think_. Parentheses in Prolog have *NO* semantic effect, they are *solely* a device for controlling grouping. It follows that ( P -> Q ) ; R *MUST* be the data structure ;( ->( P, Q ), R ) and it is this data structure which bears the meaning "if then else", *not* the surface syntax. [*], [a], and [b] are all equivalent ways of expressing exactly the same term. I regard [b] as the "correct" output for write/1, as it contains nothing superfluous. [a] has superfluous parentheses around the "_;_", they do no harm, and the listing/1 and portray_clause/1 implmentations I am responsible for would write something like [c] a(X) :- ( true -> X = 1 ; X = 2 ). But you could just as well write [d] a(X) :- ;(->(true,=(X,1)),=(X,2)). and it would *be* the same term as [*], [a], [b], or [c]. > I would have thought that this was a bug, but is it? Not at all. read/1 is doing precisely what it *must* do! Apart from being infix operators, :-, ->, and ; have no special meaning to read/1, and assert/1 or its compiled equivalent *must* not give a tinker's about what the source form happened to look like. > However, if you enter (the workaround) (I did want to use code like > the above but obviously replacing "true" with some predicate) ... > b( X ) :- ( true -> X = 1 ; fail ) ; X = 2 . I am rather puzzled as to why anyone would want the effect of call((P -> Q)) ; R can you show us what you were trying to do? Another possibility would have been to write ((P -> Q), true ; R) ;(','(->(P,Q),true),R) or (true, (P -> Q) ; R) ;(','(true,->(P,Q)),R) The rule of thumb is to never use P->Q on its own. This is doubly advisable because there are otherwise excellent Prolog systems which interpret a bare P->Q as P->Q;true. > Is this a parser problem or not? No, it is a parser WORKING. -- The purpose of advertising is to destroy the freedom of the market.
alf@sics.se (Thomas Sj|land) (03/01/91)
in his article ok@goanna.cs.rmit.oz.au commenting on the questions of dave8@and.cs.liv.ac.uk: >Parentheses in Prolog have *NO* semantic effect, >they are *solely* a device for controlling grouping. It follows that > ( P -> Q ) ; R >*MUST* be the data structure > ;( ->( P, Q ), R ) >and it is this data structure which bears the meaning "if then else", >*not* the surface syntax. This last point shows a design decision in earlier Prologs which now and then causes problems. ok ends with some words of wisdom: >The rule of thumb is to never use P->Q on its own. This is doubly >advisable because there are otherwise excellent Prolog systems >which interpret a bare P->Q as P->Q;true. > >> Is this a parser problem or not? > >No, it is a parser WORKING. Just because it is "WORKING" doesn't mean the design is not unnecessarily confusing. The design decision to use A->B;C for if-then-else wasn't very clever in my opinion. I hope the standard will not be backwards compatible on this point. Even 'A->B|C' would be much better, if '|' was not immediately translated into ';'. Maybe we could use some other operator when we are not talking about disjunctions. ---Read Richard's book, someone might quote it, and you better be informed. -- Thomas Sjoeland SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Tel: +46 8 752 15 42 Fax: +46 8 751 72 30 Internet: alf@sics.se ......