Common Lisp：为什么 delete-if if 与 remove-if 结合 setf 有如此大的不同？

中天 • • 问答 • 275 阅读

我试图对集合执行破坏性操作，并注意到 delete-if 在 SBCL 和 GNU CLISP 中给了我令人惊讶的结果。

将 setf 与 remove-if 组合按预期工作，但我不明白为什么 delete-if 不修改列表。

这是我的代码

(format t "trying weird delete-if problem~%")

(defun data ()
  (loop for x from 1 to 9 by 2 collect (cons x (1+ x))))

(defparameter *c1* (data))
(defparameter *c2* (data))

(format t "*c1* is now ~A~%" *c1*)
(format t "*c2* is now ~A~%" *c2*)

(delete-if
 (lambda (x)
   (progn
     (format t "trying to compare ~A ~A~%" x (equal x (cons 1 2)))
     (equal x (cons 1 2))))
 *c1*)

(format t "now trying remove-if~%")

(setf *c2* (remove-if
            (lambda (x)
              (progn
                (format t "trying to compare ~A ~A~%" x (equal x (cons 1 2)))
                (equal x (cons 1 2))))
            *c2*))

(format t "*c1* is now ~A~%" *c1*)
(format t "*c2* is now ~A~%" *c2*)

回答

使用时delete-if，您仍然必须将返回值分配回保存原始列表的变量。这是因为破坏性删除会改变列表的身份。

如果列表非空，则列表的身份是其第一个 cons 单元格；否则它的身份是符号，nil如果它是空的。如果破坏性删除操作产生的列表是nil（当前一个列表不是nil）或产生的列表在前面具有不同的 cons 单元格，则身份已更改。在这种情况下，必须将新身份分配回保存列表的位置。

由于列表具有引用语义，对列表的破坏性操作并不意味着我们不必为变量分配任何内容。因为 Lisp 列表是对单元格或对 的未封装引用nil，当我们破坏性地使用列表时，我们必须将存储列表的位置视为列表工作定义的一部分。破坏性列表不是简单地对列表或其他的所述第一小区的参考nil，但是破坏性列表是地方保持这样的参考否则nil。

在破坏性地处理列表时，您几乎总是希望只有一个地方。它是列表的一部分；破坏性列表通常不应存在于两个地方。

我们可以为自己创建一个delete-if-place宏，用于从包含序列的地方删除，类似于如何push和pop处理一个地方。

最简单的方法是使用define-modify-macro; 不幸的是，该宏想要使用过滤函数，将位置的值作为最左边的参数，而delete-if将其作为第二个参数。我们可以编写一个包装函数alt-delete-if来反转两个参数：

(defun alt-delete-if (pred seq &rest args)
(apply #'delete-if seq pred args))

用alt-delete-if我们说(alt-delete-if list predicate ...)而不是(delete-if predicate list ...)。

然后我们可以：

(define-modify-macro delete-if-place (&rest args) alt-delete-if)

现在我们可以这样做：

[1]> (defvar l (list 1 2 3 4 5 6))
L
[2]> (delete-if-place l #'oddp)
(2 4 6)

该地点已更新为新列表：

[3]> l
(2 4 6)

即(delete-if-place place pred)执行(setf place (alt-delete-if pred place))，除了place只评估一次。

以上是Common Lisp：为什么 delete-if if 与 remove-if 结合 setf 有如此大的不同？的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>