Contents|Symbol Index|Up: Issues|Prev: DISASSEMBLE-SIDE-EFFECT|Next: DOTTED-MACRO-FORMS

Cleanup Issue `DO-SYMBOLS-DUPLICATES`

Status: passed, 1988? (not sure which meeting)
Category: Clarification
References: DO-SYMBOLS, CLtL p.187

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.

Proposal

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

Examples

(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X)) 
;; this may print ASYM once or twice.

Rationale

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.)

Benefits

Clarification of a situation that is currently ambiguous.

Aesthetics

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

Discussion

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.

Edit History

Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87