目标
我想有我的Common Lisp（SBCL + GNU Emacs的+煤泥）环境是有点像一个Smalltalk的形象，我想有一个大泥球的包，最好的项目举办的所有我的代码。换句话说，我save-lisp-and-die在 Emacs 中设置了 Lisp 以显示保存的图像。我迷路的地方是让它与 Swank 一起工作的合适方法。
问题
我相信在save-lisp-and-die. 但是它似乎有点脆弱，因为在更改我的 SBCL 版本或 Slime 版本时，它似乎会引发版本不匹配。
题
我错过了什么吗？人们是以这种方式工作还是倾向于将更独立的项目作为 ASDF 下的一组可加载的包？
我真的很怀念 Smalltalk 的方式，感觉每个项目的 ASDF 有点笨重，而且更植根于文件系统。相比之下，它让我想起了其他所有语言及其应用程序/项目方向。OTOH 依赖包的重新版本似乎更稳定一些。好吧，跨语言的整个版本控制地狱是另一回事。
任何提示如何做我想做的事或为什么这不是一个好主意将不胜感激。
图片
SBCL 等通用 Lisp 实现支持图像。保存内存的想法早在 60 年代就出现在 Lisp 中。
Smalltalk 从 Lisp 那里得到了这个想法。在许多 Smalltalk 实现中，图像可能是可移植的（操作系统、运行时等）——尤其是在使用独立于机器的字节码时。SBCL OTOH 编译为本机机器代码。
托管源代码
Smalltalk 添加了托管源代码的想法。Smalltalk 通常使用一个简单的数据库加上一个更改日志来存储源代码。一个做类似事情的 Lisp 是 Xerox Interlisp——但方法略有不同。
其他 Lisp 实现/IDE 不支持这种方式的托管源代码 - 只有 Xerox Interlisp 变体 - AFAIK。
防御系统
在 Common Lisp 中，defsystemASDF 之类的工具和 GNU Emacs + SLIME 之类的 IDE的使用更加基于文件系统。代码驻留在多个系统中，它们是具有系统描述的目录中的文件。
甚至不清楚将新版本的系统加载到加载旧版本的 Lisp 系统中是否有意义。一个人也许可以安排那件事，但没有什么能阻止我把它搞砸。
更新 Lisp
将像 SBCL 这样的 Lisp 从一个版本更新到另一个版本可能
您可以保存包含/捆绑运行时的图像。这样你就有了图像和运行时的正确组合。
但是当您更新运行时，您通常/经常需要在加载了代码的情况下重新生成新的兼容图像。
由于 SBCL 每月发布一次，因此有定期更新的诱惑。其他实现可能使用不同的策略：LispWorks 就是一个例子。LispWorks 的发布频率要低得多，并且会在发布版本之间发布补丁，这些补丁会加载到已发布的版本中。
更新史莱姆
我不知道是否可以通过在顶部加载新版本来更新已加载的 SLIME（已在早期版本中加载到 Lisp 系统中的 SLIME）。与 SLIME 维护者核对可能是个好主意。