Pascal Costanza  <pc@p-cos.net> 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)

    FOO
    > (deflex bar::foo 57)

    BAR::FOO
    > (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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607