[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DO-SYMBOLS: duplicates and shadowings
- To: Fahlman@CMU-CS-C.ARPA
- Subject: DO-SYMBOLS: duplicates and shadowings
- From: Jon White <JLW@SU-AI.ARPA>
- Date: Tue, 19 Mar 1985 04:56:00 -0000
- Cc: common-lisp@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 --