Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!ll-xn!ames!amdcad!sun!pitstop!sundc!seismo!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: <426@aiva.ed.ac.uk> Date: 11 May 88 17:22:53 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: jeff@uk.ac.ed.aiva (Jeff Dalton,E26 SB x206E,,2295119) Organization: Dept. of AI, Univ. of Edinburgh, UK Lines: 144 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.] Lisp has grounds > for protecting atoms, Prolog hasn't. I'm not sure why Lisp gets brought in in this way. No one has argued that Prolog should do something because Lisp does, and not all Lisps use atom-based schemes. In any case, although what you say is true, it can be misleading. The key word is "associates". In some Lisps, the things you mention are actually part of the symbol object, which may make the difference between Lisp and Prolog seem greater than it is. That is just an implementation convenience, however, and not a fundamental aspect of Lisp. If we think of looser associations instead, and that is often what we actually have, we find: * The package cell is an artifact of the module scheme and therefore not a reason for atom-based modules. * The function and value cells are just an implementation convenience. It is better to think of values being held in environments. * Both Lisp and Prolog tie a symbol to a string, namely its print name, in about the same way. * Both Lisp and Prolog can use symbols as symbolic data and associate other data with them. A convention in some Lisps is to use symbol properties in sufficiently simple cases. So you might say (setf (get 'apple 'color) 'red) where in Prolog you might say color(apple,red). These have, in my view, almost exactly the same implications for modules. Actually, I think Lisp has *less* need for atom-based schemes than Prolog because it has the alternative of using environments. To expand a bit on my remarks in previous messages (about call/1 vs. APPLY), the situation in Lisp is as follows: text --(package)--> symbol --(environment)--> procedure You do not want to decide what module a procedure is in at call time because the module should be based on where the procedure argument came from, not on where the procedure that finally uses call/1 or APPLY is. So in Lisp you have two choices: if you want to be able to pass symbols around, you can make the module division at the package point. This is what Common Lisp does. If instead you plan to pass around procedures only, distinct from their names, you can base modules on environments. That is what T and MIT's CScheme do, and Common Lisp has limited capabilities of this sort. Both methods work, because the things you pass around are already resolved with respect to modules. But Prolog doesn't have procedures as separate objects and so can't pass them around. Terms and atoms get passed instead. The Quintus module scheme attaches module qualifications to terms when it thinks the terms might eventually be called. This seems (a) a kludge and (b) incompatible with Edinburgh Prolog, strictly speaking (you get these funny terms to call, and if you look at them rather that just call them, you will see this strangeness). Note that I mention the Quintus scheme only becauase it is the one I am most familiar with. (This gives you an opportunity to show how little I know even it, I suppose.) Actually, I think the Quintus scheme is better than most. The rest of your points are good, and I will not have much to say against them. My own view is that there may not be a completely satisfactory design for Prolog modules. I have certainly not seen any proposal that has the ring of truth. > In Prolog there is a one-to-one > correspondence between atoms and character strings; all atoms are > deemed to exist at all times [Hand-wave about current_atom/1] and > the names cannot be changed. I am not yet convinced that all atom-based (so-called) schemes, and in particular schemes that cannot be dynamically reconfigured, will fail to have this property. > The elementary units with which Prolog associates information are > _predicates_, so that's what the module system should be based on. I don't see how that follows. Nor do I see why that is the only association that matters. Do I not associate information with a term or atom when I use it in a relation? > Atom-based systems reveal too much: if I have a predicate f_to_s_graph/2 > with auxiliary predicates f_to_s_graph/[3,4] -- this is a real example > from the latest internal version of library(graphs); it converts a > forest to a graph -- and want to export f_to_s_graph/2, I do *NOT* want > the auxiliary predicates to be exported as well. There may be good reasons to suppose that f/1 and f/2 are just as different as f/1 and g/1, but I have not heard a convincing argument. (I know there's a technical sense in which its true, but your own example of aux predicates shows that is not the only way to think.) At the moment, Prolog has no modules and so all predicates are visible. Since I think an imperfect scheme will be necessary in any case, I do not mind this imperfection (that all f/n will have the same visibility) all that much. > Atom-based systems make basic data operations such as term comparison > inordinately complicated. [* see below] I seem to recall that there have been atom-based schemes. I wonder how they addressed this problem. > The only atom-based module systems with which I have any familiarity > are those in Common Lisp and M-Prolog. I find both appallingly > complicated. That is a valid point, but I don't find the Quintus or NIP schemes particularly simple. They also seem to require some ad hoc patches to deal with things (like setof) that use call/1. You should also know that many in the Common Lisp community are not entirely happy with Common Lisp packages. Some feel that the earlier package system in Zetalisp was better. Certainly it was more static, with less chance for symbols to be created accidently in the wrong place. >Someone could well produce a coherent logic programming language with an >atom-based module system. (I don't know LM-Prolog well enough to tell >whether it satisfies this description.) It couldn't be a compatible >extension of "Edinburgh" Prolog, that's all. None the worse for that. What incompatibilities do you have in mind? Can a predicate-based scheme have zero incompatibilities? 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