Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!think!ames!sdcsvax!ucbvax!ji.Berkeley.EDU!citrin
From: citrin@ji.Berkeley.EDU (Wayne Citrin)
Newsgroups: comp.lang.prolog
Subject: Re: Behavior of assert and retract
Message-ID: <19702@ucbvax.BERKELEY.EDU>
Date: Tue, 14-Jul-87 13:39:10 EDT
Article-I.D.: ucbvax.19702
Posted: Tue Jul 14 13:39:10 1987
Date-Received: Thu, 16-Jul-87 06:32:30 EDT
References: <3287@bigburd.PRC.Unisys.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: citrin@ji.Berkeley.EDU.UUCP (Wayne Citrin)
Organization: University of California, Berkeley
Lines: 37
Keywords: backtracking to retract

In article <3287@bigburd.PRC.Unisys.COM> dowding@bigburd.PRC.Unisys.COM (John Dowding) writes:
>I  have just  had a  brief introduction  to Quintus  Prolog 2.0 after
>having used version 1.5 for several years.   The  behavior of retract
>has changed between these two releases.  
>
>Basically, I have  a small  program that  traverses a  set of grammar
>rules (stored in the clause database) that  is implemented  in a fail
>loop:  
>
>traverse_grammar :-
>	retract(needs_visiting(Nonterminal)),
>	visit_node(Nonterminal),
>	fail.
>
>The idea is that visit_node/1 will assert new clauses of
>needs_visiting/1  as  it  finds  new  nonterminals  that  havent been
>visited yet.  

What you describe boils down to the problem of what is supposed to happen
when the program modifies procedures referred to in active choice points.
Should the changes be visible to the active choice points or not?  My
feeling is that they should not, although this behavior is more difficult to
implement, since it requires somehow recording the state of a given procedure
at various points in the program.  It should be obvious that the fragment
listed above will behave differently when the active retract cannot 'see' the
clauses of needs_visiting/1 than when it can.  I favor fixing the visible
clauses at the time that the choice point is created since this seems to make
it easier to make informal 'assertions' about the behavior of the code
(in other words, to understand what's going on).

I stumbled on this problem a while ago when comparing two versions of C-Prolog.
I had a short correspondence with Fernando Pereira and he agreed that fixing
the visible clauses was appropriate behavior in this case, although 
implementation is more difficult.

Wayne Citrin
(ucbvax!citrn)