[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]



References: MAPCAR, MAPLIST, ... (p128);

DOLIST (p126); MAPHASH (p285);


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)

Problem Description:

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


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.

Test Case:

(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))





(POP LL)))

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

Current Practice:

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

portable way.

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.

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.