Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!gatech!udel!burdvax!lang From: lang@PRC.Unisys.COM (Francois-Michel Lang) Newsgroups: comp.lang.prolog Subject: Re: retractall and backtracking Message-ID: <10548@burdvax.PRC.Unisys.COM> Date: 12 Jun 89 21:10:25 GMT References: <575@hfserver.hfnet.bt.co.uk> <10539@burdvax.PRC.Unisys.COM> Sender: news@PRC.Unisys.COM Organization: Unisys Corporation, Paoli Research Center; Paoli, PA Lines: 40 In article <10539@burdvax.PRC.Unisys.COM> armagan@PRC.Unisys.COM (Armagan Ozdinc) writes: >In article , px@unl.fctunl.rccn.pt (Joaquim Baptista (pxQuim)) writes: >> >> Variations on this problem also arise with asserta and assertz, as in: >> >> /* this will loop forever, exhausting your heap space, >> writing 1211111111... */ >> b(1). b(2). >> exec2:- b(X), write(X), assertz(b(X)), fail. > >In Quintus Prolog 2.4, exec2 doesn't behave as you describe above. It >prints 12 and fails. An article that is very relevant to this entire discussion of retractall and backtracking is the following: @INPROCEEDINGS{DefensibleSemantics, AUTHOR="Timothy G. Lindholm and Richard A. O'Keefe", TITLE="Efficient Implementation of a Defensible Semantics for Dynamic Prolog Code", BOOKTITLE=ilpc4, EDITOR="Jean-Louis Lassez", PAGES="21-39", PUBLISHER="The MIT Press", ADDRESS="Cambridge, MA", YEAR=1987 } Lindholm and O'Keefe describe several different approaches to dynamic code---i.e., a predicate whose definition can be modified at runtime, in particular by asserting or retracting clauses for that predicate. Any program that depends specifically on whether the Prolog system that is being used implements the "immediate update" or "logical" approach to handling dynamic code will *not* be very portable! ---------------------------------------------------------------------------- Francois-Michel Lang Paoli Research Center, Unisys Corporation lang@prc.unisys.com (215) 648-7256 Dept of Comp & Info Science, U of PA lang@cis.upenn.edu (215) 898-9511