LispForum

When programming in Smalltalk, one finds that the image is ubiquitous. Most Smalltalk programmers keep many different images around on their computer--- often for years---returning to work on an image whenever its suits them. Indeed, one usually starts up Smalltalk by selecting and dragging a particular image to the VM. The image is a vital part of Smalltalk, as it performs so many functions. When one queries for all instances of a class Foo
Smalltalk answers the query by scouring through its image for the appropriate objects.

On the web are some demos of how users can debug a running Smalltalk program such as a Solitaire game or a spaceship game, making some changes in the debugger, and seeing those changes reflected immediately in the live program. The interaction between the debugger and the running program depends heavily on the image. As such, Smalltalk would not be Smalltalk were it not for its image.

Now I would like to understand how extensively Lisp uses its image. From what I can tell, while a Lisp image provides a means of saving the run-time state of a Lisp environment so that users can save and load an image to resume work, it does not quite leverage the image in the same way that Smalltalk does, because the Lisp tools are quite different from Smalltalk tools.

For example, if I were to save a Smalltalk image and restart it a year later, I could quickly reconstruct the work I was doing because there are so many visual cues available when the image starts up. Usually a System Browser is present in the image, so I can see at a glance the packages that I have loaded into the image and the classes that I was working on. If a debugger is open, I can look at the last method I was examining, and try to retrace the problem I was trying to solve.

I've been using the LispWorks Personal Edition IDE, in which SAVE-IMAGE is not available, so I am not able to experiment with Lisp images (until I pay for a full license). Can I instead ask the experienced Lispers how they use the Lisp image when they program? Are they able to recall and retrace the state of their programming when they reload an old image? Are they able to explore and query a Lisp image for information such as the allInstances query above? Does the presence of an image in Lisp greatly enhance the ability to develop code in Lisp as much as it does in Smalltalk?

I have never used Smalltalk, but as far as I can tell the image-basedness of Common Lisp is in a large part a historical artefact of Lisp Machines. CL images are really specialized Lisp Machine emulators and are required by the incremental compilation/loading semantics of the language.

Some people do use persistent images, but in my experience it is quite easy to disrupt the image enough that it is simpler to rebuild it from scratch, which means that source code is primarily stored in external text files. Saved image is then only useful for saving compilation/loading time. Running images are of course very useful for debugging, since the program can be inspected and altered at runtime.

Of course, I'm mostly using SBCL which is a free implementation without built-in IDE (Emacs/Slime is very useful, but still external tool), so I am not sure what capabilities commercial implementations have. Still, I would guess that while Lisp image system is better for development than imageless systems, it is not quite as useful as in Smalltalk.

About the allInstances query, the standard does not specify such things, and therefore they are implementation dependent. Generally the level of available introspection varies between implementations, since the standard doesn't even require memory management strategy. Such generality allows CL implementation to significantly vary in size and complexity.

Ramarren wrote:as far as I can tell the image-basedness of Common Lisp is in a large part a historical artefact of Lisp Machines. CL images are really specialized Lisp Machine emulators and are required by the incremental compilation/loading semantics of the language.

?!?


Image-based development in CL is common but not required. See for example SBCL's save-lisp-and-die. As another example, CMUCL cannot be compiled "from scratch"; the current CMUCL binaries are images that have been extensively modified for maybe 20 years.

Most introspection tools are not as point&click simple as what you describe. There are functions to iterate over all loaded packages, and functions to show all symbols (variable/function/macro/class names) in a package. IIRC, the Metaobject Protocol has some features for inspecting class instances.

I personally dislike long-term image-based development. It is too easy to forget the secret sauce which got things working; I don't feel comfortable until source files can reconstitute my REPL. How does one refactor an image or commit it to version control? Yet the drive for image-based development still affects tools such as ASDF (the de facto library loader).

I would be slightly surprised if an active CL debugger would survive being stored to an image. I also don't think the REPL is generally saved.

nuntius wrote:?!?

Was something in that paragraph wrong? Describing modern CL systems as "specialized interpreters" is I guess an exaggeration, but I am still fairly sure that semantics of a language require runtime dynamic enough to be called an image, even if a particular implementation might not be able to persist it to disk.

Lisp machines weren't the only game in town; they were something of a late player, an over-ambitious peak, a 10-year blip in lisp's history. I don't think it is accurate to call CL an emulator.

From the little I've had to do with Smalltalk, I think they have very different models.
Lisp isn't really image-oriented; you compile and load source files. You can dump an image to disk and reload it later, but (at least in SBCL) that's more of an interesting artefact and a delivery mechanism than a common way of working in the language.

CL definitely gives you abstraction, and you can interact with objects at runtime as you describe in the Smalltalk demo, but we think of that as interacting with the runtime environment, rather than the image.

If I understand correctly, if you write something in Smalltalk and want to share it with somebody else, you save an image-patch, and the recipient modifies their image with that patch. Lisp isn't like that; we share source-code (or patches to it). CL has much more in common with Java that way.
It also doesn't have an inbuild mechanism for recording and retracing your steps; the closest we get is the "dribble" function, which records our commands to a file. Personally, I use a VCS (darcs, to be exact) to record the changes I've made. To make sure that I've made the changes I think I have, I'll shut down the runtime, start it back up and reload the package, which recompiles and reloads files as necessary - this allows me to make sure I'm relying on changes to the actual sources, rather than a fluke side-effect of something I've done interactively. But then, I'm also a sysadmin by profession, so I'm inherently paranoid about things like that

As Ramarren points out, you could try SBCL, which has the save-lisp-and-die feature for saving and reloading images. Its mechanism will be different from what Lispworks uses, but will allow you to experiment with that approach.