DO-SYMBOLS: duplicates and shadowings

[Jon White <JLW@SU-AI.ARPA>]

My reading of the do-symbols documentation was that "the symbols of a
package" was a colloquialism for "symbols accessible in a package", and
hence it should include the inherited symbols -- the Spice code I saw
appeared to be buggy on that score.

Perhaps we should identify the needs and the costs of the two components
in your "revised" suggestion.  
1) I have no need [currently!] for removal of duplicates, but would be
   willing to listen to someone who claims such a need.  As for cost
   of implementing this, it sounds like Hedricks 3+ hashtable lookups
   [on average] per symbol "done" is th best contender.  That could
   easily make some simple cases an order of magnitude slower.
2) In at least one case I know of, it would be rather disastrous for a
   shadowed symbol to be "done", in addition to the shadowing counterpart.
   As for cost of removing shadowed potential inheritees, I would like
   to hear some estimates on the average number of shadowing symbols
   in a package that has an earnest need for some shadowing.  The one
   example I can think of off-hand is a language emulator which is a
   variant on Common Lisp -- the non-standard, conflicting definitions
   have to be shadowed; in the example I'm thinking of, it is still less 
   than 100 shadowings.  The answer to this question may affect the
   strategy for shadowed-symbol omission, and hence the cost.

Just for the record, one may have duplicates arise because the same
symbol is inherited from several different used packages; IMPORT is not
the only villain here.

-- JonL --