Path: utzoo!attcan!uunet!mcvax!ukc!its63b!aiva!jeff
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.prolog
Subject: Re: Atom-based module systems
Message-ID: <446@aiva.ed.ac.uk>
Date: 16 May 88 16:11:28 GMT
References: <136@vor.esosun.UUCP> <841@cresswell.quintus.UUCP> <365@aiva.ed.ac.uk> <531@ecrcvax.UUCP> <963@cresswell.quintus.UUCP>
Reply-To: jeff@uk.ac.ed.aiva (Jeff Dalton,E26 SB x206E,,2295119)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Lines: 40

In article <963@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
] The point is that information about atoms and functors is held in
] predicates.  Property lists in Lisp are something of a disaster (you
] cannot use properties freely, but have to check that the system isn't
] using the name you have in mind;

You also have to check that anything you load in doesn't use the same
properties.

] Using
] predicates in Prolog is the analogue of using hash tables in Common Lisp.
] Using predicates, you can associate arbitrary chunks of information
] *without* complicating the implementation of atoms and functors, and you
] have to support predicates anyway!

Using predicates are to me much more like using property lists: they
are a single, global data base, and so it is always possible that different
code will use the same predicate or the same data structure for different
things.

     (setf (get 'apple 'color) 'red)


and

     color(apple,red).

seem much closer to each other than to something like

(let ((color-table (make-hash-table)))
  (defun get-color (object) ...)
  (defun set-color (object color) ...))

where the hash table is known only to those two functions.  Here
the table plays the role of the globally visible name "color" in
the first two cases, but it is not global.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton