lisp - Common Lisp - 名称冲突 我认为包系统应该保护我免受

Question

周末，我遇到了一个很难追查的名称冲突，但我设法将其归结为一个简短的例子 - 事实是，我认为包系统应该保护我免受此影响，所以我'想知道将来会怎样。

如果我这样做:

(ql:quickload "cl-irc")

(defpackage #:clash-demo
  (:use #:cl
        #:cl-irc))

(in-package #:clash-demo)

;; This is the name that clashes - I get a warning about this if I compile
;; this interactively (i.e. from slime) but not if I quickload the whole project.
(defun server-name (server)
  (format nil "server-name ~a" server))

;; This needs an IRC server to work - if you have docker
;; then this will do the trick:
;;
;;     docker run -d --rm --name ircd -p 6667:6667 inspircd/inspircd-docker
(defparameter *connection*
  (cl-irc:connect :nickname            "clash-demo"
                  :server              "localhost"
                  :port                6667
                  :connection-security :none
                  :username            "username"))

在上面之后，我在定义 server-name 时收到以下警告:

WARNING: redefining CL-IRC:SERVER-NAME in DEFUN

如果我尝试打印 *connection* 会出现以下错误(在我更成熟的项目中，我定义的类中缺少一个插槽 - 我认为根本原因我发现的问题和上面的最小示例都是一样的):

Control stack guard page temporarily disabled: proceed with caution

虽然如果我以交互方式定义事物时会收到警告，但实际上我将一堆代码移到了 quickproject:make-project 和 ql:quickload 中 -编辑了它，我认为它消除了警告，因为它总是干净地加载，因此我花了这么长时间才找到名称冲突。

我的问题是:

1. 包系统不是应该保护我免受这种情况吗？我想我可以理解为什么会发生上述情况 - 读者已经看到符号 server-name 所以它认为我指的是已经定义的 cl-irc:server-name，并重新使用它 - 但包系统肯定应该以某种方式允许我解决这个问题？

2. 当我quickload-ed 项目时，我假设警告是无声的，因为quickload 假设我不想看到来自项目的警告，是当我加载我正在制作的项目时，有一种方法可以使它更有力，从而引发错误，或者至少警告我这些名称冲突？据我所知，还有很多还没有给我带来问题。

我希望 (i) 名称不会冲突(即我的文件将定义符号 clash-demo:server-name，而不是重复使用 cl-irc:server -name 并导致它被重新定义)或 (ii) 这是一个错误，或者至少是当我 quickload 项目时的警告。

非常感谢您的任何建议!

Answer 1

简而言之，不:包系统并不是为了保护您免受这种情况的影响。如果你使用一个包 CL-IRC 然后你说你想要，例如，当你输入 时得到符号 CL-IRC:SERVER-NAME >服务器名称。您没有说的是您是否应该被允许以任何方式修改与该符号关联的值，这是一个正交问题。包系统只是关于名称，而不是值。

在函数的情况下，在多个上下文中定义具有给定名称的函数通常是错误的(但不总是!考虑加载补丁)。对于不太清楚的变量:如果在不同上下文中给定变量有多个 def* 形式，这可能是一个错误，但简单地分配给变量可能没问题。

因此，需要一种定义宏(defun 等)的方法，以便能够检测到这一点并进行投诉。

CL 没有提供这样的机制。然而，许多实现会这样做，要么通过检测“不同的上下文”(我一直对此含糊不清)，要么通过提供一种方式来说明某些包是神圣的并且不应允许重新定义，或者两者兼而有之。

在这种情况下，实现已警告您有关重新定义的信息，但 Quicklisp 可能已将其抑制。我不确定如何在 Quicklisp 中消除这样的警告。

总而言之，答案是控制和限制重新定义的问题与包系统所做的事情是正交的，不幸的是，CL 没有为第二个问题提供标准解决方案。

---

如果您有兴趣，我有一个小垫片，它使用条件系统来确保警告在这样的上下文中被视为错误。我可以将它附加到这个答案中，但可能要等到圣诞节之后。