| Rob Warnock wrote:
| > p.p.s. Note that there's a long-standing problem in CMUCL with
| > DEFINE-SYMBOL-MACRO expansion, that fails no matter which of
| > the above you use. ...
| Thanks Rob. It sounds like symbol macros aren't settled and are
| subject to bugs in some implementations.
Symbol macros *are* "settled": they're in ANSI Common Lisp:
Remember, Common Lisp is defined by the ANSI standard, *not* by
any particular implementation, and *especially* not by the bugs
and/or standards-conformance issues of any particular implementation.
The bug in CMUCL is understood, and a fix is in progress. There is
no reason to avoid symbol macros unless you both must use CMUCL
*and* cannot wait for a fix. [If you want to fix it yourself, the
problem is in "src/code/eval.lisp", in the function MACROEXPAND-1.
If you compare the first COND there with the similar one in the
MACRO-FUNCTION function just above, the fix may be obvious.]
If you're using any other implementation of CL, it probably
| Then there's the proliferation of multiple deflex macros...
This statement verges on FUD. Since DEFLEX is not part of the
standard, of *course* there are multiple versions. But that's
no different than any other useful abstraction that is not part
of the standard, such as socket libraries.
| ...each with its own problems.
As far as I know, there are two main approaches which work just
fine across implementations: One expands FOO to #.(MANGLE-NAME 'FOO)
[for some choice of #'MANGLE-NAME) and uses DEFPARAMETER to set
the initial value of #.(MANGLE-NAME 'FOO); the other expands FOO
to (SYMBOL-VALUE 'FOO) and uses the (LOCALLY (SPECIAL FOO) (SETF
(SYMBOL-VALUE 'FOO) ...)) hack to set the initial value. I personally
have always used the first, because on the implementation I use most
[CMUCL] it generates slightly better code than the second. But YMMV.
There was *one* erroneous approach [expand FOO to #:FOO] which I
mistakenly presented in an earlier posting because I forgot that
it breaks separate compilation. My apologies for any confusion
generated by that.
| Also, if there are multiple source files, are the backing variables
| going to be the same?
For both of the above working approaches, yes. But to make it truly
useful in that case you will need a separate version of the macro
[definition of which is left as an exercise for the reader] that
doesn't initialize the variable, but only defines the symbol macro.
I myself have only ever had to do this once, but it sounds like your
application might need it more.
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607