[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: adding namespaces to emacs-lisp (better elisp?)

From: Pascal J. Bourguignon
Subject: Re: adding namespaces to emacs-lisp (better elisp?)
Date: Sat, 27 Jul 2013 12:31:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> * `import': Importing a symbol into a package.  Importing makes the
>> symbol *present*, not just *accessible* in the importing package.
>> If a different symbol with the same name is already accessible in the
>> importing package then a user-correctable error is raised: `import'
>> avoids letting one symbol shadow another.
> Sounds like CL's approach requires symbols to be present in several
> packages, which might require more changes than I'd like in the way
> obarrays and symbols work.

Depends on what you mean by "present".  

Symbols cannot be interned inseveral packages.  They can be interned
only once, and in a single package.

cl-user> (defpackage :a (:use))
#<Package "A">
cl-user> (defpackage :b (:use))
#<Package "B">
cl-user> (intern "AA" :a)
cl-user> (import 'a::aa :b)
cl-user> (find-symbol "AA" :a)
cl-user> (find-symbol "AA" :b)
cl-user> (intern "AA" :a)
cl-user> (intern "AA" :b)

The symbol named "AA" with which I played there, was interned only in
the package named "A", and only once (in the first call to INTERN).
Once I've imported this symbol in the package named "B', it is visible
there: FIND-SYMBOL and INTERN find it.  But it's still the symbol named
"AA" interned in the package named "A".

Notice that import may also intern a uninterned symbol into the give

cl-user> (let ((s (make-symbol "S")))
           (import s :a))
cl-user> (find-symbol "S" :a)

But that's not the usual case.

You can find a "reference" implementation of a CL package system in:

Notice in find-symbol

how the notion of "present" symbol only comes in the last place before
three other ways to find symbols in packages, some of them that may not
be interned in any way in that package (:inherited).

__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]