Lisp doesn't really have separate release/debug modes[1]. When you want to distribute a program as a binary, you dump the image and set a custom top-level function to use instead of the default REPL. The program will still contain the compiler/interpreter and can redefine everything just like during development (altough the program might not use or expose those features to the user). The REPL isn't in any way magical in Lisp; it's just the default option for interacting with the Lisp.

[1]: You can ask the Lisp to drop all debug information as an optimization, which makes development impractical, but still possible. Some implementation might allow you to distribute a program without the compiler, but the standard does not specify that.

Lisp doesn't have that in the language standards, but Lisp implementations provide that. Lisp developers had the problem of shipping smaller applications, shipping faster applications to end customers, targetting systems where GC is problematic, or deploying on embedded systems.

Lisps with extensive image-based delivery support are for example Allegro CL and LispWorks. Delivery here means also deep cuts into the software like removing parts of the Lisp system (everything development relatied, unused functionality, ...) and also removing parts of the program for the delivered application. For example the running program might not need much of the program's symbols. Functions would be called directly and not through symbols.

There are also compilers for application delivery (some are inhouse) which generate self-contained C code. These then are compiled with the usual C compiler and generate small static applications. An example would be mocl, which can compile for Android, iOS and macOS platforms.

This is why I usually speak of JIT for development and AOT for distribution, as a model.

What you get depends on the error handling. You could also show a read-eval-print-loop on error or make it configurable by turning this on and off. On a Lisp Machine, the user of an application usually would get a dialog with the restart options (something no other typical operating system provides) and one option is to drop into a debugger or an error read-eval-print-loop. For some commercial systems this could be hidden from the user.

Far as restarts vs crashes, Burroughs MCP could do something similar albeit not as impressive or flexible:

"To accomplish such enhanced protection, a newer mechanism was introduced in the mid 1990s. In an unfortunate and misguided attempt at compatibility, it was named after the then-proposed C++ language construct of the same name. Because the syntax and behavior of the two differ to such a large extent, choosing the same name has only led to confusion and misunderstanding.

Syntactically, 'try' statements look like 'if' statements: 'try', followed by a statement or block, followed by 'else' and another statement or block. Additional 'else' clauses may follow the first. During execution, if any recoverable termination occurs in the code following the 'try' clause, the stack is cut back if required, and control branches to the code following the first 'else'. In addition, attributes are set to allow the program to determine what happened and where (including the specific line number).

Most events that would result in task termination are recoverable. This includes stack overflow, array access out-of-bounds, integer over/under flow, etc. Operator (or user) DS is not recoverable except by privileged tasks using an UNSAFE form of try.

MCP thus provides a very fault-tolerant environment, not the crash-and-burn core-dump of other systems."

> This isn't a very fair comparison as the Lisp code is shown running in the REPL, not in some sort of release mode that, even in Lisp, would presumably not drop you into the REPL.

This is not correct. There isn't such distinction between "release mode" and "debug mode"; the runtime -which includes the repl, interactive condition debugging and other nicetimes- is always available. It is not a thing you only get "in debug mode".

What you can do, if you want, is to enable some optimizations and drop some debug info. For example you can put, on your code:

   (proclaim '(optimize (speed 3) (safety 0) ( debug 0)))

... and this will tell the compiler that your code wants ludicrous speed, that you don't care about safety or additional debug info. But you will still have the repl and everything.

I didn't say the REPL wasn't available, I said dropping you into the REPL would not be the default action on an unhandled condition. Others have confirmed that this is the case.

Thank you anyway for your remarks.