dowding@bigburd.PRC.Unisys.COM (John Dowding) (07/11/87)
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. In Quintus Prolog 1.5 (and I believe CProlog) this will work. It does not work in Quintus Prolog 2.0, Symbolics Prolog, and Quintus Prolog on the Xerox Lisp machines. This seems to me to be reasonable program to write. Perhaps it becomes more reasonable if I specify that I want the new clause asserted with assertz, rather than asserta. I think that it captures the behavior that I want very succinctly. What do all the Prolog wizards have to say about this? Thanks, John Dowding dowding@bigburd.prc.unisys.com [ Please dont reply with lots of other ways to solve this problem (except perhaps for comparitive purposes). Im not asking for programming assistance. I know of plenty of other solutions.] --
citrin@ji.Berkeley.EDU (Wayne Citrin) (07/14/87)
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)
debruyn@philtis.UUCP (F.W.G.M. de Bruyn @ Philips CAD Centr) (07/16/87)
In article <19702@ucbvax.BERKELEY.EDU> citrin@ji.Berkeley.EDU.UUCP (Wayne Citrin) writes: >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 don't think this should be used as an argument in favour of fixing the set of branch destinations in a choice point at the moment of calling. Facilities for hypothetical reasoning (that's what's being asked for) should be implemented through a partitioned clause-base (in other words: modularity). It would be interesting to learn from Fernando Perreira (C-prolog) and Richard o'Keefe (ok@quintus.uucp) what arguments pro and con they weighed when opting for this route. -- +---------------------------------------------------------------------------+ | Frank W.G.M. de Bruyn, Philips Advanced Developments/ Applied AI | | PO. box 218, Rm. HKJ P830, NL-5600 MD Eindhoven, THE NETHERLANDS | | ARPA/CSNET: mcvax!philtis!debruyn@seismo.css.gov | | BITNET/EARN/EAN/JUNET: debruyn@philtis.uucp | | USENET/EUNET/ACSNET: {seismo, munnari}!debruyn@philtis.nl | | JANET: ukc!mcvax!philtis!debruyn | +---------------------------------------------------------------------------+