CLHS: Issue MAPPING-DESTRUCTIVE-INTERACTION Writeup

#

## Issue MAPPING-DESTRUCTIVE-INTERACTION Writeup

    Issue:          MAPPING-DESTRUCTIVE-INTERACTION
    References:     MAPCAR, MAPLIST, ... (p128);
    	        DOLIST (p126); MAPHASH (p285);
    	        DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
    	        All functions using :TEST
    Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
    Category:       CLARIFICATION
    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?

    Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):

     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.

    Test Case:

     (LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
       (DOLIST (FOO L)
         (INCF I)
         (IF (EQ FOO 'B)
    	 (SETF (CDR LL) NIL)
    	 (POP LL)))
       (LIST I L)) might return (2 (A B)) or (3 (A B)), for example.

    Rationale:

     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.

    Benefits:

      users would be more informed.

    Aesthetics:

      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.

    Discussion:

      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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.