[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I think this takes care of the loose ends for APPEND-DOTTED.
 * Added information about Kyoto CL and Xerox CL current practice.
 * Added discussion of (APPEND '() T).
 * Added parallel mention of NCONC.

Issue:        APPEND-DOTTED
References:   APPEND (p268)
Edit history: 27-Jul-87, Version 1 by Pitman,
	      29-Oct-87, Version 2 by Pitman (loose ends)
Status:	      For Internal Discussion

Problem Description:

  The description of APPEND on p268 is not adequately clear on the issue of
  what happens if an argument to APPEND is a dotted list.


  Define that the cdr of the last cons in any but the last list given to
  APPEND or NCONC is discarded (whether NIL or not) when preparing the
  list to be returned.

  In the degenerate case where there is no last cons (i.e., the argument
  is NIL) in any but the last list argument, clarify that the entire argument
  is effectively ignored. Point out that in this situation, if the last
  argument is a non-list, the result of APPEND or NCONC can be a non-list.

  Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
  the same, since these two might legitimately differ in situations involving
  dotted lists. As such, deciding which to use is not just a stylistic issue.

Test Case:

  (APPEND '(A B C . D) '())       => (A B C)	;Proposed
  (NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C)	;Proposed

  Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).

  (APPEND '(A B . C) '() 3)       => (A B . 3)	;Proposed
  (NCONC (LIST* 'A 'B 'C) '() 3)  => (A B . 3)	;Proposed

  (APPEND '() 17)   => 17			;Proposed
  (NCONC (LIST) 17) => 17			;Proposed


  This function is used a lot and its behavior should be well-defined across
  implementations. This proposal upholds the apparent status quo in a number
  of implementations.

Current Practice:

  Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
  interpretation (at least in the interpreter).

  Xerox Common Lisp and Kyoto Common Lisp signal errors when using APPEND
  or NCONC on a dotted list.

Adoption Cost:

  Technically, the change should be relatively small for those
  implementations which don't already implement it. However:

  If there are any implementations which have microcoded APPEND or NCONC
  incompatibly, the small change may nevertheless be somewhat painful.

  Some implementations may have optimized their APPEND or NCONC to expect
  only NIL when SAFETY is 0. In this case, depending on implementation
  details, requiring an ATOM check rather than a NULL check may slow
  things down.


  Since non-lists are allowed as a last argument and since APPEND and 
  NCONC can therefore produce dotted lists, some readers may have
  (incorrectly) assumed that APPEND and NCONC can reliably deal in
  general with dotted lists, something that doesn't appear to be guaranteed
  by a strict reading. The proposed extension would happen to legitimize
  such assumptions.

Conversion Cost:

  This change is "upward compatible".


  Whether or not users will think this improves the aesthetics of the
  language will depend largely on how they view the relation between
  lists and dotted lists. Those who view dotted lists as a special kind
  of list may feel differently than those who view lists as a special
  kind of dotted list.


  Pitman supports the proposed extension.