[pjmlp]

> You'll have to patiently elaborate more for me.

They are image based, so you can just save your session and continue using it later in another day.

> I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out.

On those systems, the unit of loaded code is a module and the whole OS only has dynamic libraries as executables.

So you can just reload a module and the next time you do module.proc on the repl, you will be referring to the newly loaded module.

For me an ideal REPL should be like the experience I used to have in Smalltalk.

[agentgt]

Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments).

I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.

[lispm]

> I had no idea that common lisp had image saving!

Lisp has image saving since around 1960...

[agentgt]

I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.

[lispm]

> given that is apparently how you distribute executable lisp code

LispWorks can:

* save images

* create optimized images/applications for delivery, using a treeshaker for removing unused stuff

* can generate Mac applications with the usual ceremony/ application bundles

* can generate shared libraries which can be linked into programs written in C or similar

Some other compilers can generate standalone C code doing whole-program compilation. For example mocl or some inhouse compilers used by companies.