Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Atom-based module systems Message-ID: <943@cresswell.quintus.UUCP> Date: 7 May 88 04:10:29 GMT References: <136@vor.esosun.UUCP> <841@cresswell.quintus.UUCP> <365@aiva.ed.ac.uk> <395@aiva.ed.ac.uk> Organization: Quintus Computer Systems, Mountain View, CA Lines: 57 In article <395@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes: > By saying call/1 is basically an EVAL, I meant that it brings in the > problems that EVAL does while APPLY does not. One extremely important problem that EVAL brings in which APPLY does not, and which call/1 does not bring in either, is the need for QUOTE. > By the way, Richard, are you still opposed to the so-called atom-based > module schemes? I suppose it should be a separate topic... 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. 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. The elementary units with which Prolog associates information are _predicates_, so that's what the module system should be based on. [A typed system could handle constructor functions as well as predicates.] 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. Atom-based systems make basic data operations such as term comparison inordinately complicated. [* see below] 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. 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. [* see here] Of course, a Prolog system which is embedded in or otherwise closely coupled with a Common Lisp implementation has to cope with the fact that Common Lisp *has* an atom-based package system, like it or not. Since this is a reasonable approach to implementing a Prolog system (I am saying this in the hope of tricking potential competitors into trying it...) I think that a Prolog standard should address this issue. (And yes, this _is_ a swipe at the BSI/ISO substandard.) Prolog need not be able to perform all the Common Lisp symbol/package operations, but the Prolog operations should be defined so as to do something sensible when given any atoms that the Lisp part manages to throw at it. I actually have a specification for this. The main gap at the moment is defining the term comparison order of distinct atoms with the same name; it looks as though this has to be implementation- dependent, and may have to be allowed to change between queries.