APPEND-ATOMAPPEND-DOTTED, as passed by X3J13, contains a minor technical flaw: it can be construed as leaving undefined the case where an argument to APPEND other than the last is an atom. The relevant paragraph of that issue proposal is:
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.
Here is the nit: the use of "i.e." leads one to believe that the only degenerate case defined is that where the argument is NIL. I suspect that "e.g." was intended, so as to make all atomic objects ignored in other than the last argument.
APPEND or NCONC can be a non-list.NIL is treated as an empty list and therefore effectively ignored, and any other atom is an error. 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.APPEND-ATOM:IGNORE:
(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d) ;Proposed (NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d) ;Proposed
(APPEND 'GUACAMOLE 17) => 17 ;Proposed (NCONC 'SAUERKRAUT 17) => 17 ;Proposed
Under APPEND-ATOM:ERROR these cases would all be errors.
APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list") consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.
APPEND-ATOM:ERROR would at least resolve a possible ambiguity.
KCL, and Symbolics Common Lisp all signal an error in both interpreted and compiled code.APPEND-ATOM:IGNORE should be relatively small for those implementations which don't already implement it. However, implementations which have microcoded APPEND or NCONC incompatibly may find the small change 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.
APPEND-ATOM:IGNORE would happen to legitimize such assumptions.
The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to operate on lists, and it is mildly offensive to let it accept atoms, and worse yet to ignore them. Furthermore, a certain amount of useful error checking may be lost.
APPEND-ATOM:IGNORE, but with some qualms. He raises it mainly because of the possibility that APPEND-DOTTED:REPLACE was not worded exactly as intended. TITAN TITAN è)(k Ôhß' 6¶=zº*start* 11179 00024 USa Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU> Redistributed: xerox-cl-cleanup^.pa Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 12 JAN 89 20:38:03 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 20:36:21 PST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520764; Thu 12-Jan-89 23:34:36 EST Date: Thu, 12 Jan 89 23:34 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: APPEND-FIASCO (Version 2) To: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <890112233424.7.KMP@BOBOLINK.SCRC.Symbolics.COM>