🚀 go-pugleaf

In article <1372@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>In article <2537@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>>I'm not sure just what kind of atom-based thinking I'm supposed to be
>>guilty of.  In the past, it's been claimed that atoms are different in
>>Lisp because of property lists, or something like that.
>
>Lisp has lots of things that can be defined (e.g., functions, macros,
>variables, structures, ...) which need to be put into packages.  So
>maybe it was thought to be easier to modularize Lisp by putting symbols
>in packages, rather than by putting definitions into packages.
>
>That argument doesn't apply to Prolog, however, since Prolog programs
>only define predicates.

I guess the first thing to say is that, as far as I know, none of my
statements in favor of atom-based schemes have been the result of
applying this sort of many-namespace thinking to Prolog.

The second thing to say is that some versions of Lisp have only
one namespace.  That is, there's only one mapping from names to
values instead of the several there are in Common Lisp.

Indeed, even in a Lisp with several namespaces it's still possible for
modules to come between symbols and values (so to speak) rather than
between source text and symbols (which is more or less what happens in
packages).

You're probably right that it's easier to take the package approach
in Lisp.  It's taken a while for the Scheme folk to come up with
good alternatives that fit well with macros, and more work would be
required in order to adapt such ideas to Common Lisp.  It's probably
easier in Prolog too.

However, one important factor in favor of packages turns out to be
fairly analogous to what happens in Prolog.  That is, in Common Lisp
it's possible to pass symbols as functional arguments as well as being
able to pass actual function objects.  For example, I can say:

   (mapcar 'f '(a b c))

It would be nice if F were already resolved with respect to modules
so that it would be clear which function in which module it meant.
Similarly, in Prolog, one can pass terms, or even atoms which get
made into terms via =.., and call them using call/1.  So it would
be nice if terms (and atoms) were already resolved with respect
to modules.

This argument doesn't apply to Scheme, because in Scheme you can
use only actual function objects in this way.  However, similar
problems appear when you introduce macros.  For example, if a
macro call expands into

   (mapcar f '(a b c))

it would be nice to know which F (and which MAPCAR) in which
module was meant.

Some rather complex renaming or syntactic closure mechanisms
are used to deal with such problems.  I would like to think there
was some way to deal with them in Prolog and that we just haven't
discovered it yet.

-- Jeff