length

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 27 August 1987, 14:14:28 EDT
    From: Timothy Daly <DALY@ibm.com>

    Is (LENGTH '(3 . 3)) an error?

Yes, but it doesn't necessarily signal an error.

    Lucid Common returns 1.
    Symbolics Common returns error.

This is reasonable and consistent. You're talking about a situation
which is beyond the scope of the specification.

[By the way, as a point of terminology, programs don't "return" errors,
they signal them. Indeed, signalling an error is what one does when one
doesn't want to return.]

    The bible states:

    p248:  length takes a sequence
    p245:  sequences are lists and arrays
    p27:   often the term list refers either to true lists or to dotted lists.
	   When the distinction is important, the term "true list" will be
	   used to refer to a list terminated by nil. Most functions
	   advertised to operate on lists expect to be given true lists.
	   Throughout this manual, unless otherwise specified, it is an
	   error to pass a dotted list to a function that is specified
	   to require a list as an argument.
    p27:   implementors are encouraged to use the equivalent of the predicate
	   ENDP whenever it is necessary to test for the end of a list.
	   Whenever feasible, this test should explicitly signal an error
	   if a list is found to be terminated by a non-nil atom. However,
	   such an explicit error is not required ....

    It seems that one should 'signal an error' and that it 'is an error'
    but, well, maybe not.

The wording you cite is extremely clear to me. The situation is an error.
Implementations are encouraged to signal an error (Symbolics does this)
but are not required to (Lucid does this).

    comments? Has this been resolved before?

Probably -- though in fact there is nothing really to resolve. The point of
"is an error" situations is that we're telling programmers that they cannot
depend on the behavior of their programs in this situation. See the bottom
of p5 -- it is technically legitimate for (length '(3 . 3)) to do anything
at all.

   -----
    Date: Fri, 28 Aug 87 09:05:15 PDT
    From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)

    In addition to your list of quotes from CLtL pertaining to (LENGTH '(3 . 3)),
    I refer you to page 265, which says that "LIST-LENGTH could be implemented
    as follows:

      (defun list-length (x)
	(do ((n 0 (+ 2 n))
	     (fast x (cddr fast))
	     (slow x (cdr slow)))
	    (nil)
	 (when (endp fast) (return n))
	 (when (endp (cdr fast)) (return (+ n 1)))
	 (when (and (eq fast slot) (> n 0)) (return nil))))
    "

    The use of 'endp' here seems to imply that Lucid's implemention is not
    in conformance with CLtL.  The decision to admit non-standard lists
    everywhere in the sequence functions was taken long before my coming
    to Lucid, and no one now seems to remember exactly why it was decided
    that way.  But I have heard claims that the matter was discussed with 
    Guy Steele in the fall of 1984, and he concurred (so goes the claim) 
    that signalling an error on non-standard lists isn't required.

Don't sell your people short, Jonl. I think the current Lucid position is
completely defensible. (It happens not to be the behavior I'd prefer
personally, but my objections would be aesthetic, not biblical.) The use
of ENDP is what makes it optional whether you support dotted lists. The
description of ENDP on p264 quite clearly says it is "false for conses,
true for NIL, and an error for all other arguments." p5 defines what
"is an error" means and it's quite liberal in what interpretations it
allows. Now, the implementation note which follows suggests that if it is
not going to signal an error, it should return T for non-null atoms
(which Lucid presumably does), but I'm not completely convinced that even
that behavior is forced (because of its placement in a note rather than
in the text of the definition and because the text of the definition is so
unambiguous).