From: Scott L. B. <Sc...@sy...> - 2008-04-28 02:52:49
|
Quoting Brian Mastenbrook <br...@ma...>: > > And indeed, from the CLHS entry for "pushnew": > > ``If :key is supplied, it is used to extract the part to be tested from > both item and the list element, as for adjoin.'' > > Anyway, 17.2.1 is awfully clear, but ADJOIN historically did apply the > KEY to the item. Quoth CLtL2: > > ``adjoin deviates from the usual rules described in chapter 14 for the > treatment of arguments named item and :key. If a :key function is > specified, it is applied to item as well as to each element of the > list. The rationale is that if the item is not yet in the list, it soon > will be, and so the test is more properly viewed as being between two > elements rather than between a separate item and an element.'' > > I think this rationale makes little sense I don't understand why it doesn't make sense to you. Do you agree that under the 17.2.1 interpretation, `:key' is useless with `adjoin' and `pushnew'? > and evidently so did the > ANSI authors who put ADJOIN into the list in 17.2.1. The "Notes" > section does indicate that the key is applied to the function; however, > notes are non-normative. But the line you've quoted above from the `pushnew' page is from the normative section, and even mentions `adjoin'. > Somewhere I thought there was a section of the spec describing what > happens when one section contradicts another, but I can't seem to find > it. I believe that 17.2.1 probably has precedence and ADJOIN should not > apply the key to the item. Someone has mentioned this issue on a CLiki page of proposed revisions and clarifications to the spec: http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications (Search for "adjoin", it's fairly far down.) The claim is made there that "all implementations" have the CLtL2 behavior. I have verified that indeed, Allegro, LispWorks, CMUCL, CLISP, ECL, Scieneer CL, and Genera have the CLtL2 behavior. I submit that given the outright contradiction in the spec, this is not a point on which SBCL should go its own way. -- Scott |