do-xxx-symbols

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

I don't think that the term "accessible in" is ambiguous, given the
definition on page 172.  Where is the ambiguity?  So DO-SYMBOLS wants to
iterate over all of the internal and external symbols directly present
in the current package, and also those symbols that are present because
they are external in the packages used by the specified package.

I don't think we need to worry about eliminating duplicates that result
from explicit calls to IMPORT.  That would entail a lot of extra
bookkeeping and would usually not be important.  The business about
shadowing is a bit more complex.  Technically, a symbol shadowed in
package P is not accessible in P, but again a lot of bookkeeping would
be required to eliminate these.  Unless someone has a clever idea for
how to do this efficiently, we should probably revise the description of
DO-SYMBOLS to allow it to ignore this problem.  In the reare case where
a user really cares, he can check for shadowed symbols himself.  In any
event, the manual should be clarified on these two points.

In the description of APROPOS, the term "available in" is supposed to be
"accessible in", so the rules for DO-SYMBOLS should apply if the package
is specified, and DO-ALL-SYMBOLS if all packages are to be searched.

By the way, several groups have decided that the default for no package
specified is bogus, and that if no package is specified the user
probably should be given all symbols ACCESSIBLE IN the current package.
An argument of T could mean that you really do want to see ALL the
symbols, including internal compiler symbols, etc.  Opinions?

-- Scott