DO-SYMBOLS finding shadowed symbols

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Mon, 4 Mar 1985  23:24 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    In my earlier note, I sent out my view of how to patch the existing
    description.  This is my view of "how it ought to be" rather than "what
    the manual says".  Does anyone object to adopting this as the "official"
    interpretation?  The only thing I'm uneasy about is letting DO-SYMBOLS
    generate shadowed symbols, but I don't see any good alternative.

I'm also quite uneasy about this shadowed symbols issue. I see two situations:

The first is interactive. When working interactively, you resort to mapping
when the space of things you're frobbing is too large to do manually. In that
case, you want all the help you can get and writing the code to keep out
shadowed symbols may be something you forget or find very hard to write 
correctly the first time (and you may only get one chance, unless you're
very careful). Undoing an incorrect mapping operation involving INTERN may
be massively hard.

The second is non-interactive. There you have the time to write and debug
an algorithm, but you may not be thinking about the shadowed symbol case and
may forget to write it in because it doesn't occur in the scenario you're
thinking about or whatever ... so you release code that mostly works but
has a bug sitting in it just waiting to happen.

If you make DO-SYMBOLS find symbols that are technically not accessible, 
you'd better document it well. But personally, I don't advise it, even 
if it makes coding it much harder. Better you, the implementor, spend the
time doing it once right than users spend the time over and over again
correcting for your ... I was going to say laziness, but that's obviously
the wrong word for people like all the CL implementors are. Nevertheless, 
you get my point. "An ounce of prevention, ..." and all that.

As to worrying about duplicated symbols, that doesn't strike me as as big
a deal, though I'm open to arguments to the contrary.
-kmp