References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Edit history: 07-Mar-88, Version 1 by Pitman
09-Jun-88, Version 2 by Pitman
(merge Moon's comments and update current practice)
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
"structure traversing" operation to destructively modify the
structure in a way that might affect the ongoing traversal operation.
For list traversal operations, this means that the cdr chain of the
list may not be destructively modified.
For array traversal operations, the array may not be adjusted and
its fill-pointer, if any, may not be changed.
For hash tables, new elements may not be added or deleted EXCEPT
that the element corresponding to the current hash key may be
changed or removed.
For packages, new symbols may not be interned in or uninterned from
the package being traversed or any package that it uses EXCEPT that
the current symbol may be uninterned from the package being traversed
in a DO-SYMBOLS.
Note: This proposal is intended to clarify restrictions on user code
for use with structure manipulators which are not inherently
destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
may have much more complicated restrictions and are intentionally not
treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
for more discussion of such issues.
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
This clarifies the status quo.
Also, the likelihood that the user will want to destructively alter a
structure while it is being traversed is low. The likelihood that such
code would be readable and maintainable is also low. The likelihood
that a compiler could do some interesting optimization if this point
were not pinned down is high enough to be the overriding consideration
in this case.
The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
Cost of Non-Adoption:
Users would be less informed.
users would be more informed.
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
Moon generally supported version 1 of this proposal, but had some specific
criticisms about weakness of the wording which this version is an attempt to fix.