Status: Proposal FIX-TYPO passed 12/91Issue: 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.]