#

## Issue DO-SYMBOLS-DUPLICATES Writeup

    Issue:        DO-SYMBOLS-DUPLICATES
    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.

    Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED

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

    Example:

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.