#, read macro

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

    While I admit that the uses of #, are pretty esoteric, I don't think that
is sufficient reason to flush it, unless you can really convince everybody that
ALL possible uses can be handled equally well in some other way.

    The places I've seen it used where I thought it was justified have all
essentially been instances of caching.  The most common cases have involved
using #, to cache the result of the search for some special object, when the
search can't be performed at compile time.  I've also seen it used to create a
data structure once, in order to avoid consing, although this practice is
usually pretty questionable, due to multi-tasking considerations.  This kind of
usage can probably be handled about equally well by using defparameter.  There
are a couple of possible disadvantages to using defparameter though.  First, It
sort of adds to clutter, since you need to think up a name for each case of #,
(although this isn't always a bad thing), and conses up a symbol, which
requires memory.  Second, a special variable lookup might be slower than
accessing an inline constant in a given implementation; I don't thing the
reverse is very likely.  Also, using a defparameter means that someone could
change its value, though this could actually be a blessing when debugging.

    Another place where I've seen it used is to produce some unique value once
(to avoid consing), for use as the default argument to get/getf, or the eof
value for read, and similar things.  In this case it is the uniqueness of the
value (testable with EQ) that is important, which makes the defparameter
solution more likely to get broken by having someone come along and
inappropriately bash the variable.  However, it is usually (I'm reluctant to
say always) the case that this idiom can be handled using #. instead of #,.

    PCL uses a macro called load-time-eval.  It used to be the case that this
really was trying to use load-time considerations, and not just caching the
result of some computation after the first time it was done.  This macro was
supposed to be sort of an extension of #,, since the people working on PCL
considered the latter to be inadequate for what they were trying to do (which,
in fact, it is).  I believe that PCL no longer actually needs the load-time
specialness, and might in fact be better off using a caching scheme instead.  I
do know that the old PCL code in which I first saw load-time-eval was in fact
rather broken.

    Hmmm.  It seems that while I had initially intended to argue for keeping
it, while writing this I've just about convinced myself that #, can be flushed.
Well, maybe someone else can come up with an excuse for keeping it.

kab

PS. Is this list (cl-compiler) active and significantly disjoint from the main
common-lisp mailing list.  If so, I'd like to be added to it.
-------