Path: utzoo!attcan!uunet!mcvax!unido!ecrcvax!micha From: micha@ecrcvax.UUCP (Micha Meier) Newsgroups: comp.lang.prolog Subject: Re: Atom-based module systems Message-ID: <531@ecrcvax.UUCP> Date: 11 May 88 06:51:50 GMT References: <136@vor.esosun.UUCP> <841@cresswell.quintus.UUCP> <365@aiva.ed.ac.uk> <395@aiva.ed.ac.uk> <943@cresswell.quintus.UUCP> Reply-To: micha@ecrcvax.UUCP (Micha Meier) Organization: ECRC, Munich 81, West Germany Lines: 17 Posted: Wed May 11 07:51:50 1988 In article <943@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >My objections to atom-based schemes are: > Lisp associates an amazingly pile of rubbish with atoms (function cell, > property list, package cell, pname, maybe even other stuff) with atoms. > Prolog doesn't. [Hand-wave about operator properties, which are > notionally stored only in the current_op/3 table.] I don't know what is the current_op/3 table and how does the read/1 predicate access it, but in any case even in Prolog, there is more information one might want to associate with a functor: counters, recorded terms, arrays (except for recorded terms extended data types, but they *are* used). Apart from that, there are Prolog extensions that might want to associate even more information with a functor. In SEPIA, we have introduced property lists exactly because of this. --Micha