New proposed issue APPEND-ATOM

[Guy Steele <gls@Think.COM>]

Issue:        APPEND-ATOM
References:   APPEND (p268)
	      Issue APPEND-DOTTED
Category:     CHANGE/CLARIFICATION
Edit history: 06-Dec-88 by Steele

Problem Description:

The issue APPEND-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.


Proposal (APPEND-ATOM:IGNORE):

In the degenerate case where there is no last cons (i.e., the argument
is an atom) 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.

Proposal (APPEND-ATOM:ERROR)

In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
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.


Examples (APPEND-ATOM:DOTTED):

(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.


Rationale: 

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.


Current Practice:

Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.


Cost to implementors:

Technically, the change for 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.


Cost to users:

Each proposal is upward compatible.


Benefits:

Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.

Aesthetics:

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.

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.

Discussion:

Guy Steele supports proposal 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.