🚀 go-pugleaf

In article <575@hfserver.hfnet.bt.co.uk> nigel@hfserver.hfnet.bt.co.uk (Nigel Cliffe) writes:
>
>I have a problem with backtracking, and retracts that don't appear to
>happen - here is a simplified example:
...
>write_unique_foos :-
>	foo(X),
>	write(X),nl,
>	retractall(foo(X)),
>	fail.
>
>Now if the predicate "write_unique_foos" is called, then I get all three
>values for foo written, not just the two unique ones as I would expect.
>However if I trace the execution, and test the contents of the database at
>various points from the debugger then "foo(bar1)" has disappeared after the
>first call to "retractall".
>
>Can anyone explain why this happens.

Under Quintus version 2 retracts take effect immediately for any new query
started but they don't affect a query already started. This is quite a
consistent behaviour, is good semantically and avoids various inconsistencies
that would otherwise happen. Read Section 2.1 of the release notes for 
version 2.0 of Quintus.

The situation is comparable to the classic readers/writers method of ensuring
file consistency. If you have already started reading (i.e. activated a
query) then the file (relation) stays the same, but any new readers 
(activations) get the new version.

This behaviour was proposed for the Prolog standard but I gather some people 
are trying to revert to the naive method with all its inconsistencies. See
the Lindholm/O'Keefe paper in the Melbourne LP conference.

Chris Moss