Another possible Lucid bug:
> (setq a (list 1 2 3 4 5 6))
(1 2 3 4 5 6)
> (remove 1 a)
(2 3 4 5 6)
> a
(2 3 4 5 6)
>(defclass foo ()())
foo (or whatever it says)
>(setq a (make-instance foo))
foo#2 (or whatever)
>(setq b (list a (make-instance 'foo) (make-instance 'bar)))
(foo#2 foo#3 bar#1)
>(remove a b)
(foo#3 bar#1)
Ok, here's the bug...
>b
(foo#2 foo#3 bar#1)
It is not acting destructive in the sceond case, nor does it seem to be
in any case with objects. This caused me a great amount of pain (it is
hard to debug code that may not be working because of the compiler).
Question: Am I stupid, or have I found another bug? Could someone try it
on MCL or Procyon or any other CLOS?
Tom Crevier
ExperTelligence
········@jarthur.claremont.edu (The Tom) writes:
>(setq b (list a (make-instance 'foo) (make-instance 'bar)))
(foo#2 foo#3 bar#1)
>(remove a b)
(foo#3 bar#1)
Ok, here's the bug...
>b
(foo#2 foo#3 bar#1)
Sigh, the only bug is that you are not storing the result of the REMOVE
operation. REMOVE is not a destructive operation! If you want B to
hold the modified list, you must explicitly assign the result to B.
This is also true even if you use DELETE instead of REMOVE. DELETE
isn't *required* to destruct its argument -- it is only *permitted* to
do so. It may still return a value that isn't EQ to the original sequence.
-Sandra
From: David F. Skoll
Subject: Re: Lucid Error w/Remove???
Date:
Message-ID: <dfs.689637266@troi>
In <·····················@muddcs.claremont.edu>
········@jarthur.claremont.edu (The Tom) writes:
>Another possible Lucid bug:
>> (setq a (list 1 2 3 4 5 6))
>(1 2 3 4 5 6)
>> (remove 1 a)
>(2 3 4 5 6)
>> a
>(2 3 4 5 6)
First of all, that's bizarre. REMOVE is a non-destructive function;
DELETE is its destructive counterpart.
>Ok, here's the bug...
>It is not acting destructive in the sceond case, nor does it seem to be
>in any case with objects. This caused me a great amount of pain (it is
>hard to debug code that may not be working because of the compiler).
Second, I thought that destructive functions have the option of modifying
the original list or not - you shouldn't really count on their operation.
You should always use:
(setf foo (DESTRUCTIVE-FUN foo))
not just
(DESTRUCTIVE-FUN foo)
to be safe.
For illustration, in Franz Allegro Lisp 4.0, I get this behaviour:
cl> (setq a '(1 2 3 4 5 6))
(1 2 3 4 5 6)
cl> (delete 1 a)
(2 3 4 5 6)
cl> a
(1 2 3 4 5 6)
cl> (delete 2 a)
(1 3 4 5 6)
cl> a
(1 3 4 5 6)
--
David F. Skoll