Moss.UPenn%Rand-Relay@sri-unix.UUCP (10/20/83)
From: Chris Moss <Moss.UPenn@Rand-Relay> I think we should add "assert" and "retract" to the list of "GOTO-like" primitives in Prolog. It is clear that they can lead to very bad programming style. I think Richard's piece in May Sigplan is excellent (read it if you haven't already). But it raises the question of what exactly Prolog is. If we say that it is a Horn-Clause programming system whose semantics is defined exactly (E.g. by van Emden and Kowalski) then we even exclude cuts/slashes from Prolog which are accepted by nearly everyone as being an essential part of Prolog (even though parallel systems such as Concurrent Prolog will use different semantics for a similar looking idea). On the other hand, Richard's assumption that the Edinburgh implementation is normative for such things as setof is going too far in the other direction. Clearly clarity is served if we reserve one name for one type of object, but to say that you must use the word "find_all" for a flat "setof" is curious. Which implementation introduced the the word "find_all" ? I don't know. This all points out that we need a continuing clean semantics for Prolog as it is extended - that is the only way of avoiding these dissensions. Anything that can be done from within Prolog should be given a normative Prolog interpretation in the reference manual of an implementation. Things that cannot be expressed in Prolog should be given a proper denotational or similar semantics so that different implementations behave the same way. Most evaluable predicates should be actually evaluable functions. "succ" is a function: if we try to make it non-detirministic, we freeze in some totally arbitrary evaluation order which is extraneous to it. Given the system "succ" one can easily write a non-deterministic one in Prolog to suit one's need of the moment. I believe that "assert" and "retract" should have two extra parameters: the database being added to, and the database created by the additions (or deletions). In this way all the messy implementation details are eliminated. For convenience we might have an additional pair which act on the "default" database or workspace, whose names can be handled by the system. Which database one is working on at any time can then be described to the user.