[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inconsistency in backquote spec?
- To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: inconsistency in backquote spec?
- From: "Larry_Masinter.PARC"@Xerox.COM
- Date: Tue, 29 Nov 1988 14:23:00 -0000
- Cc: firstname.lastname@example.org.EDU
- In-reply-to: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28 Nov 88 18:12
- Sender: "Larry_Masinter.PARC"@Xerox.COM
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
References: APPEND (p268)
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
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. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
Define that the cdr of the last cons in any but the last argument 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.
(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
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change 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
Cost to users:
This change is upward compatible.
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.
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
The cleanup committee supports this proposal.