[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: remove



> 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