Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!munnari!mulga!lee
From: lee@mulga.UUCP
Newsgroups: comp.lang.prolog
Subject: Re: XOR without redundancy and databases
Message-ID: <1891@mulga.OZ>
Date: Mon, 6-Apr-87 00:55:38 EST
Article-I.D.: mulga.1891
Posted: Mon Apr  6 00:55:38 1987
Date-Received: Wed, 8-Apr-87 04:33:39 EST
References: <425@aramis.RUTGERS.EDU>
Reply-To: lee@mulga.OZ (Lee Naish)
Organization: Computer Science, University of Melbourne
Lines: 33

In article <425@aramis.RUTGERS.EDU> chomicki@aramis.RUTGERS.EDU (Jan Chomicki) writes:
>xor(G1,G2) :- pick(String), xor(G1,G2,String).
>
>xor(G1,G2,String):- G1, there_was_once(String).
>xor(G1,G2,String):- \+ was_there_once(String), G2.
>
>pick(String) :- new_string(String), \+ was_there_once(String), !.
>there_was_once(String):- name(_,String).
>was_there_once(String):- current_atom(Atom), name(Atom,String).
>
>new_string([112]).
>new_string([112|L]):-new_string(L).

One problem with this is that nested calls to xor may not work correctly.
The inner call can use the same string and cause it to be put in the
dictionary, even though G1 (from the outer call) fails.  This would
prevent G2 from being called. eg:

?- xor((xor(true, fail), fail), true). 	% xor is a confusing name here

fails when it should succeed (I think).  Just to stop a dozen people
sending in fixes, I guess I should point out that you can get around
this by creating two related strings, both of which must be "new"
then making one "old".  The computation may create the string in other
ways too (though this is unlikely, I guess).

was_there_once/1 could get pretty slow on some systems also (maybe slower
than finding the first solution to G1).

Can anyone confirm that default/2 in Prolog II uses soft cut?
Are there any other systems with soft cut implemented?

	lee