How to use Common Lisp sort of like a smalltalk image

Question

Goal

I would like to have my Common Lisp (SBCL + GNU Emacs + Slime) environment be sort of like a Smalltalk image in that I want to have a big ball of mud of all my code organized in packages and preferably projects. In other words I have messed about a bit with save-lisp-and-die and setting Lisp in Emacs to bring up the saved image. Where I get lost is the appropriate way to make it work with Swank.

Problem

I believe it is required to put swank hooks inside my Lisp image before save-lisp-and-die. But it seems a bit fragile as on change to either my SBCL version or Slime version it seems to throw a version mismatch.

Question

Am I missing something? Do people work this way or tend to be more separate project as a loadable set of packages under ASDF?

I really miss the Smalltalk way and feel like per project ASDF is a bit clunkier and more rooted in the file system. In comparison it reminds me too much of every other language and their app/project orientation. OTOH it seem a bit more stable-ish re-versions of depended upon packages. Well, the entire versioning hell across languages is another matter.

Any hints how to do what I want or why it isn't such a good idea would be much appreciated.

Answer 1

Images

Common Lisp implementations like SBCL support images. The idea of saved memory appeared early in Lisp in the 60s.

Smalltalk took that idea from Lisp. In many Smalltalk implementations images might be portable (OS, runtime, ...) - especially when using machine independent byte code. SBCL OTOH compiles to native machine code.

Managed source code

Smalltalk added the idea of managed source code. Smalltalk often uses a simple database plus a change log to store source code. One Lisp doing something similar was Xerox Interlisp - but with slightly different approaches.

Other Lisp implementations / IDEs don't support managed source code that way - only the Xerox Interlisp variants - AFAIK.

DEFSYSTEM

In Common Lisp the use of defsystem facilities like ASDF and IDEs like GNU Emacs + SLIME is much more file system based. Code resides in multiple systems, which are files in a directory with a system description.

It's not even clear that it's meaningful to load a newer version of a system into a Lisp system where an older version is loaded. One might be able to arrange that, but there is nothing preventing me from messing that up.

Updating Lisp

Updating a Lisp like SBCL from one version to another might

• make the saved image incompatible to the runtime
• make the compiled code in FASL files incompatible with the runtime

You might save an image with the runtime included/bundled. That way you have the right combination of image and runtime.

But when you update the runtime, you usually/often need to regenerate a new compatible images with your code loaded.

Since SBCL brings releases once a month, there is a temptation to update regularly. Other implementations might use different strategies: LispWorks is an example. LispWorks is released much less often and publishes patches between releases, which are loaded into the released version.

Updating SLIME

I have no idea if it would be possible to update a loaded SLIME (a SLIME which has been already loaded in an earlier version into a Lisp system) by loading a new version on top. Probably a good idea to check with the SLIME maintainers.