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