Re: Macros: Scheme vs Common Lisp
At 08:59 AM 8/20/98 +0200, Michael Sperber [Mr. Preprocessor] wrote:
>>>>> "Craig" == Craig Lanning
<CraigL(a)internetx.net> writes:
Craig> At 02:00 PM 8/19/98 +0200, Michael Sperber [Mr. Preprocessor] wrote:
>>>>>>> "Holger" == Holger Schauer
<schauer(a)coling.uni-freiburg.de> writes:
Can you elaborate what this does? Under CLISP, this yields:
#<PACKAGE PKG1>
Sorry, I should have explained the purpose of each form.
On Symbolics XL1200 Lisp Machine:
(defpackage pkg1 (:export foo)) ; Create package PKG1
; export the symbol FOO
=> #<Package PKG1 22006504701>
(in-package :pkg1) ; make PKG1 the current package
; (all unqualified symbols will
; be looked up in PKG1)
=> #<Package PKG1 22006504701>
(setq bar 23) ; make symbol PKG1::BAR with value 23
=> 23
(defmacro foo () 'bar) ; define macro PKG1:FOO
=> FOO
(defpackage pkg2 (:use pkg1 cl)) ; Create package PKG2
; Use packages PKG1 and COMMON-LISP
=> #<Package PKG2 22006507333>
(in-package :pkg2) ; make PKG2 the current package
; (all unqualified symbols will
; be looked up in PKG2)
=> #<Package PKG2 22006507333>
(let ((bar 42)) (foo)) ; create local variable named
; PKG2::BAR with value 42, then
; evaluate the form (PKG1:FOO)
; which expands to PKG1::BAR
=> 23
(macroexpand '(let ((bar 42)) (foo)))
=> (LET ((BAR 42)) PKG1::BAR)
Note that FOO is inherited from PKG1.
Also, I couldn't find anything offhand in CLtL2 about the
interaction
of macros and packages. Admittedly, I've been too lazy to dig up the
ANSI spec.
You won't find anything explicitly stated. A package is just a collection
of symbols. READ and INTERN create new symbols in whichever package
is the value of *PACKAGE* at the time they are called. The exception
is that INTERN accepts a second optional argument which is the package
to intern the symbol in regardless of the current value of *PACKAGE*.
In Common Lisp, macros have the same interaction with packages as
functions. A package is just a place to hold the list of symbols which
make up their definitions.
>> So what's the politically correct way to define top-level
bindings
>> which are not special in Common Lisp?
Craig> Why would you want them?
The problem with dynamic binding in Common Lisp is that a special
declaration makes a name be dynamically bound everywhere. So, when I
just look at a LET locally, I cannot tell whether it's a static or a
dynamic binding because a special declaration may be lurking somewhere
else without my knowing.
You need to be careful how you switch between the term "name" and the
term "symbol". In CL, all objects (functions, macros, variables,
classes, structures, etc.) are named with symbols. The symbols PKG1::BAR
and PKG2::BAR have the same name "BAR" but are two completely separate
symbols (not EQ and have different home packages).
(in-package :PKG3)
(defvar BAR nil)
This will cause all variable bindings of PKG3::BAR to be dynamic, but
will not affect bindings of either PKG1::BAR or PKG2::BAR.
I use global variables all the time without wanting dynamic scope for
them. Unfortunately, declaring such a variable in Common Lisp (if I
understand you right) automatically changes the meaning of all other
LET bindings for the same name, even though they, by intention, have
nothing to do with the global variables.
It is typically considered bad programming style (in any language) to
make common use of global variables. One of the main benefits of
dynamically binding global variables is to use them as global parameters
which can be modified within an execution thread and appear as global
values to all the code in the thread, but be completely invisible to
all other threads.
Of course, this mechanism is necessary to keep compatibility with
older Lisps. From a fresher perspective, I conjecture it would be
better to make dynamic scoping explicit everywhere by introducing
extra binding and reference operators.
I cannot remember ever needing a nondynamic global variable.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Craig Lanning
E-Mail: CraigL(a)InternetX.net