Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!daemon
From: miller@ACORN.CS.ROCHESTER.EDU (Brad Miller)
Newsgroups: comp.lang.prolog
Subject: Re: A Suggested Additional Predicate for Prolog
Message-ID: <7783@sol.ARPA>
Date: 16 Mar 88 20:14:08 GMT
Sender: daemon@cs.rochester.edu
Lines: 42


    Date: 12 Mar 88 07:23:48 GMT
    From: gast@CS.UCLA.EDU

    In other words, the retract should be undone on backtracking.  For
    consistency sake, an assert that is undone on backtracking should also
    be included, but the rest of this comment does not concern itself with
    a "backtrackable assert."

    By the way, assert and retract are unlike most predicates in that
    their bindings are not undone on backtracking.  This behavior is
    non-orthogonal.  Thus, I propose to have orthogonal predicates
    for adding to or deleting from the database.

It is, in fact, our current plan that RHET (a PROLOG varient implemented in
LISP primarily for KR uses rather than "logic programming") will have all
functions with side effects that can supply undo functions to automatically
get undone if they are backtracked on. So assert, retract, and possibly user
functions could be undone if an appropriate undo function is declared.

Once this is in place, it is the non-retracting assert that will be
unavailable! We currently haven't implemented it, because of some
non-trivial interactions with intelligent backtracking.

Mainly, this just discourages use of these predicates: if someone were to do
a PROVE-ALL, that is, to find all the proofs of some goal, some of whose
proof trees included ASSERTS and others that did not, it is unclear which of
these proofs will be considered "final" and not have their assertions
undone. (Prove-all generates a proof, records it, and then "fails" in order
to generate another proof).

So what this really comes down to, is you have to be very careful about
side-effects, when they are useful, and what sort of persistance (per proof,
indefinite, just the current branch, etc.) you want them to have. We
certainly haven't "solved" these problems, we will just pick some convenient
definitions (for the KR work we do) and implement that.

------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
U. Rochester Comp Sci Dept.
'If anything is True, this is.'