Pascal Costanza <email@example.com> wrote:
| Rob Warnock wrote:
| > To answer Pascal's other question, having the same package as
| > the symbol macro has two benefits: (1) If you're *not* using
| > uninterned symbols at backing variables, having the backing
| > variable match the packages of the symbol macro avoids collisions
| > between "DEFLEX FOO" forms in different packages. [This was a bug
| > in an earlier version of my DEFLEX which Adam Warner helpfully
| > pointed out in mid-2005.] ...
| OK, I understand this better now.
| However, I am not totally convinced yet. Putting such generated symbols
| in the same package has the potential of leading to other kinds of
| nameclashes, so I don't like that.
Ahhh, but you should note *what* the symbols look like that
my version of DEFLEX generates:
> (defpackage :bar)
#<The BAR package, 0/9 internal, 0/2 external>
> (deflex foo 13)
> (deflex bar::foo 57)
> (describe 'foo)
FOO is an internal symbol in the COMMON-LISP-USER package.
It is a symbol macro with expansion: *STORAGE-FOR-DEFLEX-VAR-FOO*.
> (describe 'bar::foo)
FOO is an internal symbol in the BAR package.
It is a symbol macro with expansion: BAR::*STORAGE-FOR-DEFLEX-VAR-FOO*.
Using this scheme, conflicts are (IMHO) *very* unlikely!! ;-} ;-}
| What I have come up in another (related) setting was that I interned
| such generated symbols all in a dedicated package for generated symbols,
| but the symbol names thereof are composed of their symbol package names
| and their symbol names. So, say, for a symbol P1::S1 you get something
| like SPECIAL-PACKAGE::|P1::S1|.
| Do you agree that that's a viable approach? Too complicated?
| Still too simple?
Certainly viable, but too complicated.
Mine is simpler and less ugly. (IMHO. YMMV.)
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607