From: Eric Marsden
Subject: CLHS example for NINTERSECTION
Date:
Message-ID: <wzi66bsf02b.fsf@laas.fr>
The HyperSpec includes some example code illustrating the functioning
of NINTERSECTION, which seems too restrictive for me. The relevant
code is (adding the quotes which are missing from CLHS):
,----
| (defvar *list1*)
| (defvar *list2*)
|
| (setq *list1* (list 1 1 2 3 4 'a 'b 'c "A" "B" "C" "d")
| *list2* (list 1 4 5 'b 'c 'd "a" "B" "c" "D"))
|
| (nintersection *list1* *list2*)
`----
CLHS says this should return (1 1 4 B C). CMUCL also returns "B" (for
compiled code, not when interpreted), presumably because the compiler
is coalescing the common elements of the two lists so that they are EQ
(and thus EQL, which is the default comparison function for
NINTERSECTION). Is this behaviour allowed?
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden <········@laas.fr> writes:
> The HyperSpec includes some example code illustrating the functioning
> of NINTERSECTION, which seems too restrictive for me. The relevant
> code is (adding the quotes which are missing from CLHS):
>
> ,----
> | (defvar *list1*)
> | (defvar *list2*)
> |
> | (setq *list1* (list 1 1 2 3 4 'a 'b 'c "A" "B" "C" "d")
> | *list2* (list 1 4 5 'b 'c 'd "a" "B" "c" "D"))
> |
> | (nintersection *list1* *list2*)
> `----
>
> CLHS says this should return (1 1 4 B C). CMUCL also returns "B" (for
> compiled code, not when interpreted), presumably because the compiler
> is coalescing the common elements of the two lists so that they are EQ
> (and thus EQL, which is the default comparison function for
> NINTERSECTION). Is this behaviour allowed?
The document elsewhere says that the examples are not a binding part of
the language definition. It was expected there would be cases where
they had this overly-restrictive case. I tried to show conflicting
possible results where I (a) noticed the isue and (b) had time.
In this case, CMUCL apparently coalesces the "B" constant across functions,
underscoring for all onlookers the importance of not side-effecting quoted
structure! That sounds conforming to me, so I'd not worry about it. The
critical thing you don't point out is that probably
(defun foo () "B")
(defun bar (x) (eql x "B"))
(bar (foo))
returns true when compiled in CMUCL. In many implementations it does not.
Even if I'd used the occasionally used
=OR=> (1 1 4 B C "B")
I would still have had to explain that this result was valid only subject
to the constraint in the last paragraph, and not generally on a whim. That
is, it's not like NINTEGERSECTION uses EQUAL as a predicate, even though
EQUAL approximately describes what may be coalesced in quoted literals.