common-lisp - 如何使用 Common Lisp 有点像 smalltalk 图像

Question

目标

我想让我的 Common Lisp (SBCL + GNU Emacs + Slime) 环境有点像 Smalltalk 图像，因为我想让我的所有代码都组织成包，最好是项目。换句话说，我在使用 save-lisp-and-die 和在 Emacs 中设置 Lisp 来调出保存的图像时有点困惑。我迷路的地方是让它与 Swank 一起工作的合适方法。

问题

我相信需要在 save-lisp-and-die 之前将 swank hooks 放入我的 Lisp 图像中。但是它似乎有点脆弱，因为在更改我的 SBCL 版本或 Slime 版本时，它似乎会引发版本不匹配。

问题

我错过了什么吗？人们是以这种方式工作还是倾向于将更独立的项目作为 ASDF 下的一组可加载的包？

我真的很怀念 Smalltalk 的方式，感觉每个项目的 ASDF 有点笨重，而且更 Root 于文件系统。相比之下，它让我想起了其他所有语言及其应用程序/项目方向。 OTOH 依赖包的重新版本似乎更稳定一些。好吧，跨语言的整个版本控制 hell 是另一回事。

任何提示如何做我想做的事或为什么这不是一个好主意将不胜感激。

Answer 1

图片

SBCL 等通用 Lisp 实现支持图像。保存内存的想法早在 60 年代就出现在 Lisp 中。

Smalltalk 从 Lisp 那里得到了这个想法。在许多 Smalltalk 实现中，图像可能是可移植的(操作系统、运行时等)——尤其是在使用独立于机器的字节码时。 SBCL OTOH 编译为 native 机器代码。

托管源代码

Smalltalk 添加了托管源代码的想法。 Smalltalk 经常使用一个简单的数据库加上一个更改日志来存储源代码。一个做类似事情的 Lisp 是 Xerox Interlisp——但方法略有不同。

其他 Lisp 实现/IDE 不支持这种方式的托管源代码 - 只有 Xerox Interlisp 变体 - AFAIK。

DEFSYSTEM

在 Common Lisp 中，defsystem 工具(如 ASDF)和 IDE(如 GNU Emacs + SLIME)的使用更加基于文件系统。代码驻留在多个系统中，它们是具有系统描述的目录中的文件。

甚至不清楚将较新版本的系统加载到加载旧版本的 Lisp 系统中是否有意义。一个人也许可以安排那件事，但没有什么能阻止我把它搞砸。

更新 Lisp

将像 SBCL 这样的 Lisp 从一个版本更新到另一个版本可能

使保存的图像与运行时不兼容

使 FASL 文件中的编译代码与运行时不兼容

您可以保存包含/捆绑运行时的图像。这样你就有了图像和运行时的正确组合。

但是当您更新运行时，您通常/经常需要在加载了代码的情况下重新生成新的兼容图像。

由于 SBCL 每月发布一次，因此有定期更新的诱惑。其他实现可能使用不同的策略:LispWorks 就是一个例子。 LispWorks 的发布频率要低得多，并且会在发布版本之间发布补丁，这些补丁会加载到已发布的版本中。

更新史莱姆

我不知道是否可以通过在顶部加载新版本来更新已加载的 SLIME(已在早期版本中加载到 Lisp 系统中的 SLIME)。与 SLIME 维护者核对可能是个好主意。