bimbart@kulcs.cs.kuleuven.ac.be (Bart Demoen) (11/27/90)
hello, sorry if the folowing questions seem non-relevant given a Prolog implementation with the immediate update view on database changes, what would you expect in the following situations: (I insist on the word 'expect': even if you have an implementation of the immediate update view, I am still most of all interested in your expectations) a/1 is dynamic and there is one clause for a/1: a(1) . question 1 what is the output of the query ?- a(X) , write(X) , retract(a(1)) , asserta(a(2)) , fail . question 2 what is the output of the query ?- a(X) , write(X) , retract(a(1)) , assertz(a(2)) , fail . in case you overlooked it: the difference between the queries is in assertA/assertZ ---------- in which Prolog system has the immediate update view on database changes been implemented ? can you test for me the above queries ? you can send answers to me directly, I can summarize to the net thanks Bart Demoen
roland@sics.se (Roland Karlsson) (11/27/90)
> a/1 is dynamic (and immediate) and there is one clause for a/1: > a(1) . > question 1 > what is the output of the query > ?- a(X) , write(X) , retract(a(1)) , asserta(a(2)) , fail . > question 2 > what is the output of the query > ?- a(X) , write(X) , retract(a(1)) , assertz(a(2)) , fail . In Aurora and Muse parallel Prologs there are similar implementations of immediate update of the data base. Both implementations keep a choice point until ready with the immediate predicate. So the above queries should give the output '1' and '12' respectively. But unfortunately both implementations are WRONG. If you remove the retract(a(1)) literal from both queries above then they will correctly give the output '1" and '12222...' respectively. As the one who have programmed this code for Muse I feel very ashamed (:-). I thought it was RIGHT. Looking at the code I see that retract will incorrectly remove the clause a(1) from the list of possible clauses. When adding a(2) then it will be added non reachable from the removed clause a(1). Muse had a correct, but more inefficient, implementation before. Then all clauses was kept, until reaching prolog top level, and only marked as dead. After a while this implementation resultet in VERY long search time in long lists of dead clauses. Hmmmm... Might there be an efficient AND correct solution? -- Roland Karlsson SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Internet: roland@sics.se Tel: +46 8 752 15 40 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
bimbart@kulcs.cs.kuleuven.ac.be (Bart Demoen) (12/02/90)
I got answers from F. Kluzniak, R. K. Horsell, F. Pereira, K. Verschaetse, L. Naish, R. O'Keefe, M. Brady and R. McEntire (chronological order): my thanks to all of them people seem to agree that in a correct implementation of immediate update view, the results should be question 1: ?- [user]. | a(1). | user consulted 68 bytes 3.97364e-09 sec. yes ?- a(X) , write(X) , retract(a(1)) , asserta(a(2)) , fail . 1 no question 2: | ?- [user]. | a(1). | user consulted 68 bytes 3.97364e-09 sec. yes | ?- a(X) , write(X) , retract(a(1)) , assertz(a(2)), fail. 12 no and I am very happy about this: the meaning of asserta and assertz is different even when there are no (non-retracted) clauses some systems that implementent the immediate update view correctly: DEC-10 DEC-20 Prolog CProlog in debug mode (not in non-debug mode) R. K. Horsell's own implementation(s) (about which I know nothing more) Quintus Prolog 1.x (the current Quintus version has logical view) my questions were related to a gap in the specification of database updates in Prolog (for ISO) I now am reassured that I tried to fill the gap in a way people agree with Bart Demoen