Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!nbires!hao!noao!arizona!debray
From: debray@arizona.UUCP
Newsgroups: comp.lang.prolog
Subject: Re: Prolog control structures
Message-ID: <1608@megaron.arizona.edu>
Date: Wed, 1-Apr-87 23:38:16 EST
Article-I.D.: megaron.1608
Posted: Wed Apr  1 23:38:16 1987
Date-Received: Sat, 4-Apr-87 19:47:52 EST
References: <10588@topaz.RUTGERS.EDU>
Organization: U of Arizona CS Dept, Tucson
Lines: 49
Summary: some solutions

Regarding the probloems posed by chomicki@topaz.RUTGERS.EDU (Jan Chomicki):

> 1. A predicate xor(G1,G2) which has the following behavior:
>    First, goal G1 is called.
>    If G1 succeeds, xor(G1,G2) succeeds, and can be re-satisfied
>       on backtracking as often as G1 can be.  When G1 can't be
>       re-satisfied, xor fails.
>    If G1 fails, G2 is called.
>    If G2 succeeds, xor(G1,G2) succeeds, and can be re-satisfied
>       as often as G2 can be.
> 

Assuming no side effects, the following works on most Prologs:

	xor(G1,G2) :- not(not(call(G1))) -> call(G1) ; call(G2).

> 2. Given a predicate P :- A, B, C, D.
> 
>    Is it possible to rewrite P to obtain the following behavior:
>    If the goal A initially succeeds, then
>       if B doesn't succeed, backtrack into A.  (This is quite normal.)
>    However, if A initially succeeds, and B does too,
>       then prevent backtracking into A.
> 
Again, assuming no side effects, the following will work on most Prologs:

	P :- ( not(not( (A,B) )) -> (A -> B) ; (A, B) ), C, D.

A comment in passing regarding these solutions and something the original
poster said:
> A number of us at SDC have been experimenting with some Prolog
> control structures which we have so far been unable to implement
> cleanly--i.e., without using the database.

Apparently a lot of people have a tendency to resort to "assert" or
"record" at the drop of a hat (I can see complaints that my solutions
above compute the first solution twice: once in the satisfiability test
not(not( ... )), once in the actual call).  What's often ignored is that
"assert" and "record" are *expensive*, and may end up being costlier
than recomputing the solutions.  I, personally, have found only two or
three situations where I'd say "assert" was really necessary.  I think
a little more care in coding could in most cases result in code which,
in avoiding asserts, would improve in speed, understandability _and_
portability.
-- 
Saumya Debray		CS Department, University of Arizona, Tucson

     internet:   debray@arizona.edu
     uucp:       {allegra, cmcl2, ihnp4} !arizona!debray