Subject: Re: defvar affecting captured closure variables ?
From: (Rob Warnock)
Date: Mon, 08 Oct 2007 01:51:49 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Thomas F. Burdick <> wrote:
| Kent M Pitman <> wrote:
| > Pascal Costanza <> writes:
| > > Why are the first two characteristics (no uninterned symbols, same
| > > package as the symbol macro) important?
| >
| > I never use uninterned symbols either.  They have issues with becoming
| > external data in file compilation when you've macroexpanded them.  If
| > all your uses are in one file, you may not see it, because I think
| > implementations try to eq-ify gensyms across a target stream, but if
| > you were to write them to a separate file, there is no way for those
| > two files, upon reloading, to realize they need to coalesce--their
| > symbol identities will, of necessity, diverge and they will no longer
| > be cooperating.
| Also, simply re-evaluating the deflex form should probably not make
| all references from that point on be disjoint from all references
| compiled up to that point.

Yup, that's precisely the main reason I don't like uninterned
symbols as "backing variables" for lexicals. In what I use DEFLEX
for, it is *very* common for the DEFLEX form to be re-evaluated
or even changed slightly and *then* re-evaluated [as when editing
a source file and re-loading it into the running image]. The latter
is also why my DEFLEX expands into a DEFPARAMETER of the backing
variable rather than a DEFVAR. I *want* the (re)evaluation of a
(possibly-modified) DEFLEX to be able to change the variable and
all extant references to it.

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.]  And, (2) if you *do* use uninterned
symbols at backing variables, then when debugging you sometimes
don't know to *which* DEFLEX form a "#:FOO" refers (which package
the symbol macro came from), since all you have is the debugger
error message that's complaining about something in the expansion,


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607