Thread View: comp.lang.prolog
3 messages
3 total messages
Started by Claude Duguay
Wed, 30 Sep 1992 16:57
retract*all
Author: Claude Duguay
Date: Wed, 30 Sep 1992 16:57
Date: Wed, 30 Sep 1992 16:57
15 lines
983 bytes
983 bytes
This may seem sill or I might be missing part of this conversation but
would it not be easier and just as portable to use a simpler
implementation of retractall/retract_all rather than creating elaborate
solutions to emulate compiler directives:
myretractall(Term) :-
retract(Term),
fail.
myretractall(_).
Appologies for any naivety resulting from my focus on PDC Prolog and
restricted experience with other versions of Prolog.
Claude Duguay cduguay@lcraft.ersys.edmonton.ab.ca
Re: retract*all
Author: Fergus James HENDERSON
Date: Thu, 01 Oct 1992 06:18
Date: Thu, 01 Oct 1992 06:18
18 lines
1221 bytes
1221 bytes
cduguay@lcraft.ersys.edmonton.ab.ca (Claude Duguay) writes: >This may seem silly or I might be missing part of this conversation but >would it not be easier and just as portable to use a simpler >implementation of retractall/retract_all rather than creating elaborate >solutions to emulate compiler directives? The problem is a general one, so we want a general solution. retract_all is just one example, there are undoubtably many others. Also a user's implementation of retract_all may be much less efficient than the built-in implementation. -- Fergus Henderson fjh@munta.cs.mu.OZ.AU This .signature virus is a self-referential statement that is true - but you will only be able to consistently believe it if you copy it to your own .signature file!
Re: retract*all
Author: Richard A. O'Keefe
Date: Tue, 06 Oct 1992 04:49
Date: Tue, 06 Oct 1992 04:49
54 lines
2577 bytes
2577 bytes
In article <uLBXRB2w165w@lcraft.ersys.edmonton.ab.ca>, cduguay@lcraft.ersys.edmonton.ab.ca (Claude Duguay) writes:
> This may seem sill or I might be missing part of this conversation but
> would it not be easier and just as portable to use a simpler
> implementation of retractall/retract_all rather than creating elaborate
> solutions to emulate compiler directives:
> myretractall(Term) :-
> retract(Term),
> fail.
> myretractall(_).
There are two snags:
(1) There may be substantial performance advantages to using the built in
method. (For example, Quintus Prolog uses the Lindholm/O'Keefe model
for data base changes, and retractall/1 could count as one "clock tick"
rather than several.)
(2) In a Prolog with modules, such as Quintus Prolog or ALS Prolog, you will
have to add some kind of declaration to myretractall/1, while the built
in version is already module-aware.
(3) The really big problem is that the indicated code for myretractall/1 is
wrong. For example, if I have
p(a).
p(b) :- q(c).
then retractall(p(_)) is supposed to retract _both_ clauses, but this
definition will only retract the first. You would need
myretractall(Term) :-
clause(Term, _, Ref),
erase(Ref),
fail ; true.
Because some Prolog vendors have not provided clause/3 and erase/1, you
would have to do something like
myretractall(Term) :-
clause(Term, Body),
my_retractall_aux(Term, Body),
fail ; true.
my_retractall_body(Head, Body) :- Body == true, !,
retract(Head),
!.
my_retractall_body(Head, Body) :-
retract(Head :- Body),
!.
It would all really be much simpler if vendors would just provide retractall/1
with the same name and semantics.
--
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants. Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads