[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remove
- To: "Mark A. Tapia" <markt@dgp.toronto.edu>
- Subject: Re: remove
- From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
- Date: Fri, 27 Nov 92 16:03:24 GMT
- Cc: info-mcl@cambridge.apple.com
- In-reply-to: Mark A. Tapia's message of Fri, 27 Nov 1992 09:09:40 -0500
> Many people have commented at great length about using remove
> (remove-if and remove-if-not), noting that
> The result of remove may share with the argument sequence; a list
> result may share a tail with an input list and the result may be
> eq to the input sequence if no elements need to be removed"
> This general comment is also applicable to other non-destructive
> sequence modifiers, including remove-duplicates, and substitute,
> when the argument is a list. However, while the operations are allowed
> to share a tail with the input sequence, they are not required to.
>
> Does this mean that it is safer to copy the list first and then
> apply the destructive functional equivalent?
It depends on what you're doing.
For example, SORT is destructive and so you may want to sort a
copy, thus:
(sort (copy-list x) #'<)
Moreover, since you can't rely on REMOVE making a copy, you
might find yourself doing something like this:
(sort (copy-list (remove nil x)) #'<)
In this case, it's also reasonable to copy first and use DELETE:
(sort (delete nil (copy-list x)) #'<)
However, there are times when you're not doing anything that
modifies list structure, and then you can use REMOVE and similar
functions without any trouble.
-- jd
- Follow-Ups:
- Re: remove
- From: poeck@informatik.uni-wuerzburg.de (karsten poeck)