do-xxx-symbols

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

Due to some kind of mail problem I didn't see this conversation until today.

We take DO-SYMBOLS to mean to iterate over all symbols accessible to this package,
including ones that are inherited from other packages.  That seems like the most
reasonable interpretation of what the manual says.  I agree with Scott that the authors
of the manual never imagined that other interpretations were possible.

We provide DO-LOCAL-SYMBOLS as an extension.  It iterates over only symbols present
in the specified package.

Our DO-SYMBOLS has the usual bug with shadowed symbols: its iteration includes symbols
that would have been inherited had they not been shadowed.  I think it's clear that
this is a bug and not an allowable interpretation of the manual.

Our DO-SYMBOLS has the usual bug with unnecessarily imported or exported
symbols: its iteration sees a symbol more than once if that symbol is imported
even though it would have been inherited, or is exported from two used packages.
Perhaps this case is rare enough in practice, and difficult enough to test for,
that the manual should be changed to say that a symbol can be seen more than once,
as Scott suggested.

Of course, certain implementations of packages (ones that hash symbols
redundantly in every package that inherits them, so that INTERN need do only
a single hash lookup regardless of the length of the use-list) would never
encounter such bugs.  Perhaps the language should be based on such a simple
implementation as a standard, and other implementations that try to save
space are responsible for not deviating from that standard.  Opinions?