CLHS: Issue LOOP-FOR-AS-ON-TYPO Writeup

#

## Issue LOOP-FOR-AS-ON-TYPO Writeup

    Status:         Proposal FIX-TYPO passed 12/91
    Issue:  	       LOOP-FOR-AS-ON-TYPO
    Reference:      X3J13/89-004 page 2-10, CLtL/II page 721, and dict-flow.tex
    Category:       Clarify/fix-typo
    Edit History:   Version 1  20-Aug-91 by JonL

    Problem Description:

     From the draft proposal .tex file, under the subsection {\bf for-as-on-list},
     the words:

         In the {\it for-as-on-list\/} subclause,
         the {\tt for\/}
         or {\tt as\/} construct iterates over the contents of a
         @type[list]. It checks for the
         end of the @type[list] as if by using
           @funref[endp].

     were erroneously copied verbatim from the subsection {\bf for-as-in-list},
     rather than the intended wording from the Iteration Subcommittee.

     At one level, this prescription doesn't make sense;  by saying that
     it is iterating over the "contents", rather than down the successive cdrs,
     of the list, there is confusion about the values assumed by the variable
     [which is subsequently said to take on the "tails" of the list.]

     In the spring of 1988, the Iteration Subcommittee suggested a change from
     the then existing practice of terminating both LOOP-FOR-AS-IN and
     LOOP-FOR-AS-ON by simply a NULL test.  [Indeed, in the MacLisp days before
     CommonLisp, ENDP didn't exist; and the common use of NULL rather than ATOM
     was based on a performance hack for the PDP10 Architecture.]  So ENDP was
     specified for LOOP-FOR-AS-IN because that style views the list as a sequence
     having "contents" or elements; but ATOM was specified for LOOP-FOR-AS-ON
     since the only concern was the succession of list tails.  The LOOP-FOR-AS-ON
     case is intended to be more general -- and hence have a less restrictive
     termination test -- so that user-defined iteration over non-standard
     lists can be supported.  But the current draft specification completely
     and accidentally defeats this design.

    Proposal (LOOP-FOR-AS-ON-TYPO:FIX-TYPO)

     Restore the original wording as intended by the Iteration Subcommittee
     as follows:

        In the {\it for-as-on-list\/} subclause,
        the {\tt for\/}
        or {\tt as\/} construct iterates over a
        @type[list]. It checks for the
        end of the @type[list] as if by using
          @funref[atom].

    Editorial Impact:

     Very small.

    Rationale:

     The evidence that this is a typo is in the Lucid Product Documentation
     of about the same time that 89-004 was abstracted from it; this product
     documentation has the "correct" wording, and the person responsible for
     doing the abstracting simply copied over the wrong, albeit very
     similarly worded paragraph.  The two paragraphs are close together
     in that text.

     Without this fix, there will surely be gratuitous variations as to
     how the termination testing is done for the LOOP-FOR-AS-ON case.

    Current Practice:

     Some existing implementations still adhere to the MacLisp inspired
     version that used to be distributed from MIT, which simply used NULL
     for both the FOR-AS-IN and the FOR-AS-ON cases; some adhere to a
     later Common Lisp version that uses ENDP, at least for the FOR-AS-IN
     case.  Harlequin has apparently implemented the broken semantics of
     "X3J13/89-004 page 2-10".

    Discussion:

     This typo has gone undetected for over two years, between January 1989
     until about April 1991, when a fresh implementation of LOOP taken purely
     "from the spec" produced anomalous results on LOOP-FOR-AS-ON termination
     tests.  Lawrence G. Mayka <lgm@iexist.att.com> noticed the variation when
     comparing Harlequin's LOOP implementation with some of the others.

     Jonl 11-Apr-91:  I know this (the use of ATOM for FOR-AS-ON termination)
        was discussed and agreed upon; and I hope that the forum of discussion
        was within X3J13, either the iteration subcommittee or the whole
        committee.  I even recall changing Lucid's implementation after this
        decision. [And an edit-history record of that change, along with the
        rationale cited above, still exists in the Lucid source code for
        Loop, dated 9-May-88.]

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