Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!harpo!seismo!hao!hplabs!sri-unix!SHardy@SRI-KL
From: SHardy%SRI-KL@sri-unix.UUCP
Newsgroups: net.lang.prolog
Subject: Use of Assert
Message-ID: <13254@sri-arpa.UUCP>
Date: Tue, 1-Nov-83 09:17:55 EST
Article-I.D.: sri-arpa.13254
Posted: Tue Nov  1 09:17:55 1983
Date-Received: Sat, 5-Nov-83 19:10:11 EST
Lines: 37

A recent message suggested that users wanting to use ASSERT and
RETRACT (to model, say, a network) should not use the built in
definitions but instead re-implement those operations using, the
message said, a tree like term to represent a personal database,
I.e.:
        tree(PROPOSITION, LEFTSUBTREE, RIGHTSUBTREE).

This tree would be passed as an explicit extra argument to all
predicates.  This approach, it was suggested, is both cleaner and
more efficient than using ASSERT.

I have a comment and a question.  The comment is that programs
are no cleaner for being written by users than by system programmers.
A program written using terms as a personal database will be just as
hard to analyse automatically (say) as a program using ASSERT and
RETRACT.  The reason for this is that the TREE term has as its
intended interpretation a collection of propositions, unlike most
terms whose interpretation is some object in the real world.
Propositions, such as HUMAN(STEVE, TREE), start having bizarre
interpretations too.  Mixing terms and meta-terms in the same
program always leads to confusion irrespective of who does it,
user or system.

The question is addressed mainly to Prolog implementors.  Does
anyone know of a Prolog implementation that, like Genesereth's
MRS, uses different representations for stored propositions
depending on the use those propositions get ?  For example, the
following code:

        setq(L, R) :- retract(eval(L, R)), assert(eval(L, R)).

provides something close to assignment.  A smart Prolog system
could recognize the code and store EVAL as a collection of
ordinary Von Neumann variables.

-- Steve Hardy,
   Teknowledge