🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.prolog
Article #2745

Re: multiple copies of a clause in the DB

#2745
From: Saumya Debray
Date: Sat, 08 Aug 1987 15:30
46 lines
2737 bytes
In article <1696@super.upenn.edu>, tim@linc.cis.upenn.edu (Tim Finin) writes:

> Most Prolog implementations allow the database to contain two
> identical clauses. [...] I have never found a use for this in practice.
> In fact, it has only effected my life by being a source of bugs.  It
> is easy enough to accidentally get multiple copies of a clause in the
> database by consulting a file instead of reconsulting it or by defining
> the same predicate in two different files.  This can easily mess up
> your program ...

In my view, in this case the underlying implementation should provide
something that focuses on efficiency, without taking away from the user
the flexibility of imposing additional constraints if he so desires.
If I don't care about the presence of duplicate clauses, I shouldn't have
to pay the price of checking for duplicates; on the other hand, if I do
care about duplicates, it's easy enough to extend "assert" to take care of
this, e.g.:

   my_assert((H :- B)) :- clause(H,B) -> true ; assert((H :- B)).
   my_assert(Fact) :- clause(Fact,true) -> true ; assert(Fact).

Since "consult" is basically a read-assert loop, the analogous extension
of "consult" to "my_consult" is straightforward.

Such an approach is flexible enough to handle stronger notions of what
constitutes "redundancy" in the database as well, e.g. if I wanted to
ensure that only those facts were asserted that were not provable from
what's already in the database, I'd write something like

   my_assert(X) :- not(X), assert(X).   [*]

Of course, with this "my_assert" is no longer guaranteed to terminate,
but that's the user's problem.

[* This only works for ground facts, of course, but you see what I'm
getting at.]

In summary: language constructs should be designed so that (i) users
don't have to pay for features they don't use; and (ii) users should
have the flexibility of extending the basic language features to do
what they want without undue suffering.
-- 
Saumya Debray		CS Department, University of Arizona, Tucson

     internet:   debray@arizona.edu
     uucp:       {allegra, cmcl2, ihnp4} !arizona!debray
Technical Details
Message-ID: <1871@megaron.arizona.edu>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!hao!noao!arizona!debray
References: <1696@super.upenn.edu>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!hao!noao!arizona!debray
From: debray@arizona.edu (Saumya Debray)
Newsgroups: comp.lang.prolog
Subject: Re: multiple copies of a clause in the DB
Message-ID: <1871@megaron.arizona.edu>
Date: Sat, 8-Aug-87 11:30:10 EDT
Article-I.D.: megaron.1871
Posted: Sat Aug  8 11:30:10 1987
Date-Received: Sun, 9-Aug-87 11:59:10 EDT
References: <1696@super.upenn.edu>
Organization: U of Arizona CS Dept, Tucson
Lines: 46
Keywords: database
Summary: implementation efficiency