DO-SYMBOLS finding shadowed symbols

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

I've been having some second thoughts about shadowed symbols in
DO-SYMBOLS myself.  It really is pretty dirty conceptually to have
DO-SYMBOLS supply anything that is not really accessible in the package.

I guess there are some ways that implementors could hack this without
incurring unacceptable costs.  For example, we could set a bit
somewhere, either in the symbol itself or in the hash-table entry, for
any symbol that has ever been shadowed in any other package.  For the
small minority of symbols with this bit set, we would have to do the
extra checking to make sure that it really is accessible; for all other
symbols, we could skip this.  We wouldn't have to worry about un-setting
this bit if a symbol gets un-shadowed -- it's just a heuristic.  There
are lots of variations on this theme.  The point is that it need not
involve unacceptable overhead to eliminate shadowed symbols, though it
does make a bit of extra work for implementors.  I guess I'd opt in this
case to keep the language clean rather than the implementation.

So my revised suggestion is that DO-SYMBOLS does provide all accessible
symbols including those inherited via USE-PACKAGE.  It will present each
symbol at least once (may be more than once in cases of explicit
importantion), but will not present any symbols that are not really
accessible in the package in question due to shadowing.

-- Scott