[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


There is no apparent consensus on this issue. Various folks
said they would like a version that had keywords and didn't like
allowing duplicates, but in lieu of a consensus for change, we're
left with the status quo. 

This version removes the ADD-KEYWORDS alternative proposal, and
adds to the discussion.

I removed an awkward phrase which read 

"Users who have been assuming [no duplicates]...
will have to be modified."

although perhaps that is what we mean.

References:   DO-SYMBOLS, CLtL p.187
Category:     Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
              Version 2 by Masinter 29-May-87
              Version 3 by Masinter 23-Nov-87

Problem Description:

CLtL specifies that DO-SYMBOLS executes the body once for each symbol
accessible in the package.  It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed).  It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.


Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.


;; this may print ASYM once or twice.


Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates.  For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications.  Users who really
want the duplicates to be removed can add additional code to do this job.

Current Practice:

Many implementations have always produced duplicate values.

Cost to implementors:

None.  Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.

Cost to users:

Code written assuming that DO-SYMBOLS eliminates duplications
will have to be modified. (Such code was not truly portable.)


Clarification of a situation that is currently ambiguous.


It would be cleaner to present each symbol exactly once.  This is a
clear case of choosing efficiency over elegance.


This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.

The need for do-symbols to be efficient is questionable, however; for 
many applications (e.g., global package manipulation), duplicate values
would create havoc. 

For some implementations, the performance penalty would be well over 
a factor of two.

Several proposals were considered for adding keyword arguments
to DO-SYMBOLS which might specify :ALLOW-DUPLICATES, adding keywords
and eliminating DO-EXTERNAL-SYMBOLS, etc., but no clear consensus
was reached for making additions.

This version is the closest to the status quo.