From: Thomas A. Russ on
RG <rNOSPAMon(a)flownet.com> writes:

> In article <ymioch6xilo.fsf(a)blackcat.isi.edu>,
> tar(a)sevak.isi.edu (Thomas A. Russ) wrote:
>
> > jimka <jimka(a)rdrop.com> writes:
> >
> > > On Apr 25, 6:01 pm, p...(a)informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > jimka <ji...(a)rdrop.com> writes:
> > > > > 4. All keywords go into the same package. "KEYWORD". What causes the
> > > > > evaluator to evaluate keywords to themselves? Is it that they exist
> > > > > in this package? The CL syntax for keywords is that the a : preceed
> > > > > the name. Other than this extremly handy syntax, is there any other
> > > > > reason one might want all keywords in the same package?
> > > >
> > > > (eq ':x ':x) --> true is a good reason.
> > > >
> > >
> > > Maybe there is somthing fundamental that I misunderstand about CL
> > > packages. Isn't it possible for symbols in two pacakges to be eq?
> >
> > No. Symbols in two packages are definitely not EQ. They cannot be the
> > same object.
>
> Of course they can. You yourself point this out:

OK. Based on a correction of my view of how IMPORT works I need to
revise this. What you get with import is the same symbol present in
more than one package, but it is the same object. And you have to do
this with IMPORT. Using another package merely makes the symbols
accessible.

You cannot make separate symbols from two different packages be EQ.
They must be the same symbol, either through IMPORT or USES in order for
you to get EQ results. In all such cases, it will be the case that the
SYMBOL-NAME and the SYMBOL-PACKAGE will be the same.


> > Now, if you IMPORT a symbol from package A into package B, then you just
> > have one symbol that is ACCESSIBLE (via the reader) from either
> > package. But it is just one symbol, namely the one in package A.
> >
> > For example, if you did
> >
> > (defpackage a)
> > (in-package :a)
> > 'a
> >
> > (defpackage b (:import a::a))
> >
> > (eq 'a 'a::a) => T
> >
> > (symbol-package 'a) => <Package A>
> > (symbol-package 'b::a) => <Package A>
>
> Here's an even starker example:
>
> ? (make-package :p1)
> #<Package "P1">
> ? (make-package :p2)
> #<Package "P2">
> ? (import 'p1::x :p2)
> T
> ? (eq 'p1::x 'p2::x)
> T
> ? (eq (intern "X" :p1) (intern "X" :p2))
> T

Actually, INTERN does not necessarily create a symbol in the given
package. It just makes sure that a symbol with that symbol name is
accessible in that package. If you continue your example you get

(home-package (intern "X" :p1)) ==> #<Package "P1">
(home-package (intern "X" :p2)) ==> #<Package "P1">

> You are confusing the concept of being interned in a package with the
> concept of a symbol's home package. A single symbol can be interned in
> multiple packages, but it can have at most one home package. A symbol
> need not have a home package to be interned in one or more packages:

I suppose this depends on what you actually mean by being interned in
mulitple packages. If you take what I think is the standard lisp
interpretation, I would say that a symbol is interned in only one
package, namely its home package. But if you want to read it as
allowing you to call the INTERN function in different packages, then we
would be using the terminology differently.

The CLHS glossary uses this definition for intern:

"intern v.t. 1. (a string in a package) to look up the string in the
package, returning either a symbol with that name which was already
accessible in the package or a newly created internal symbol of the
package with that name."

So the first part of interning a symbol in a package just means looking
it up, and thus it isn't any different than saying you can lookup a
single symbol in multiple packages.

Now, based on your notes below, I do see that IMPORT behaves differently
than my mental model had it work.

> ? (symbol-package 'p1::x)
> #<Package "P1">
> ? (unintern 'p1::x :p1)
> T
> ? (symbol-package 'p2::x)
> NIL
> ? 'p2::x
> #:X


> > > Isn't this what the :use keyword does on defpackage? It assures you
> > > that the symbols with the same name are eq.
> >
> > No, what :USE does is import all of the exported symbols of the named
> > packages.
>
> No, what :use does is make those symbols accessible by inheritance.
> This has much the same effect as importing all the external symbols of
> the used package, but it specifically does NOT cause those symbols to be
> present (which is a precisely defined term in CLHS) in the using
> package.

Ah, thanks.
Even after all these years I still learn new things about CL.



--
Thomas A. Russ, USC/Information Sciences Institute
















From: Tim Bradshaw on
On 2010-04-27 17:36:06 +0100, RG said:

> Sorry, my sarcasto-meter was set to hair-trigger mode.

No problem.

Actually, I'll reinforce my post: I'm pretty sure that the moment when
I felt I really understood the package system was when I suddenly
understood the difference between a symbol being visible in a package
(via a used package), being present in the package (by being imported)
and actually belonging to the package. These are very important
distinctions.

From: Duane Rettig on
On Apr 25, 8:54 am, jimka <ji...(a)rdrop.com> wrote:
> > 4. All keywords go into the same package. "KEYWORD".  What causes the
> > evaluator to evaluate keywords to themselves?  Is it that they exist
> > in this package?  The CL syntax for keywords is that the a : preceed
> > the name.  Other than this extremly handy syntax, is there any other
> > reason one might want all keywords in the same package?  Is there an
> > reasonable argument to allow keywords in other packages?   Restated,
> > suppose a lisp did not support the : synax for keywords but insisted
> > that keywords by identifyable by their inital character being "?".
> > Would their be an advantage for that lisp to force all such keywords
> > into the same package?
>
> > -jim
>
> It's obvious from the responses to this question that the question is
> not stated very well. :-( Let me retry.
>
> Common lisp, keywords happen to have three very useful properties.
> 1. they always evaluate to themselves
> 2. they always parse to the same symbol, regardless of the value of
> *current-package*
> 3. key all have (are in) the same package: "KEYWORD"

Careful here; you're taking only one definition of the word
"keyword". A keyword can actually be _any_ symbol. Look it up in the
Glossary.

Duane