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