Show HN: My book, The Common Lisp Condition System

That's a really impressive way of both continuing the conversation and sneaking in extra improvements to your book!

There's an issue with 4.6.8: You can't use saved images to debug errors in SBCL, because SBCL's SAVE-LISP-AND-DIE function throws the stack away.

Just bought it. Thanks for writing this, and thanks for your continuing participation in discussions of CCL issues on github.

It is the latter.

It is possible to implement a condition system on top of any language that has dynamic variables, a `finally`-style construct and some mechanism for unwinding the stack. Since dynamic variables are implementable on top of lexical variables and `finally`, it's basically just about unwinding the stack and `finally`.

The main issue is how a condition system would fit with any existing system which likely works by immediately unwinding the stack rather than allowing to wind it further; that's the case e.g. in Java or C++.

In principle most other compiled languages could have macros that manipulate the abstract syntax tree. Lisp makes it easy since there is little separation between the source code and AST, but Scala now has macros despite using totally different syntax.

What phoe-krk mentions is indeed the main thing that blocks “real” integration into existing languages with exceptions: they always unwind before executing the handler. (JWZ even complained about this while writing about Java.)

To expand on their comment: if `throw` in Java or C++ is similar to `error` in CL (or `throw` in some special cases), a `catch` clause in Java or C++ is equivalent to a label, where the `try` binds a handler that exits to it immediately. There's no equivalent of putting code in the handler other than a single unwind-and-jump, and there's no equivalent of restarts.

In CL, a condition handler gets called on top of the existing stack and can inspect what's going on before choosing where to exit to. Other functions in the call stack can provide alternative exits (restarts), like “continue processing anyway” or “substitute a placeholder value”; these are dynamically named, rather than lexically bound like `catch` . So there's a lot more possible decoupling, at least in theory. The equivalent of `finally`/destructors is `unwind-protect`, which has to interoperate with the condition mechanism but doesn't deal with conditions itself.

In C++ or Java, you could implement the restarts with a (thread-local) stack of restart descriptions plus try/finally or constructor/destructor, and the same for handlers, and then do your nonlocal exits with specialized throwables. I did something similar in Lua, in fact, while trying to extend it into a fancier language. But a “normal” `throw` will bypass all of that. That's not dangerous if you do the unwind-protects properly, but none of your existing libraries will be built for it, and the results will be kind of anemic.

In the Java-style objects+throw/catch world, similar things can be achieved by toggling “what to do if X happens” state or plumbing callback pointers through the object graph beforehand, which is similar but more ad-hoc, and possibly harder to add to existing systems. That said, the CL style proper is very tied to the call stack, which can also make things tricky.

From Appendix E:

> It is also noteworthy that this aspect of the condition system is fully independent from Lisp’s homoiconicity; rather, it is a consequence of the way other programming languages are designed. For instance, when one divides by zero in a Java program, then there is nothing carved in stone which would prevent the language from winding the stack further and executing some code that will analyze the dynamic environment in which the error happened, calling all error handlers found in the dynamic environment, and then—if no handler transferred control outside the error site—either entering an interactive debugger of some sort or giving up and crashing. However, Java goes a different way: it immediately destroys the stack by throwing an exception. That is a design choice which was made by the Java creators; Lisp’s homoiconicity has nothing to do with this fact, as can be demonstrated by the multiple independent implementations of condition systems in non-homoiconic languages that we have mentioned earlier.

Macros for python have been recently proposed [1], and oh boy aren't they ugly!

[1] https://www.python.org/dev/peps/pep-0638/

Thank you for the congrats, and the fact that it wasn't described anywhere is the reason for my original frustration, which in turn is the reason why this book exists.

I hope that the book is useful for you; in case of any questions, please feel free to ask me and/or make issues on the GitHub repository of the book. In the worst case, I'll create or expand the book's errata... or write yet another appendix.

Both. The book contains an explanation of how to derive the condition system from the primitive operators of Common Lisp, which should be useful both for users that try to gain some intuition or broaden their understanding of how the condition system works under the hood, and for people who want to implement a condition system in a programming language without one - be it Common Lisp or a different language.

Implementing a condition system in a Common Lisp implementation is actually a mostly solved problem, since one can use e.g. https://github.com/phoe/portable-condition-system or borrow some code from an already working Common Lisp implementation.

It's not that "analogous".

Take a peek, it doesn't unwind the stack unless you ask it to, which gives it much more power than exception handling in languages such as Java.

Not exactly. The Common Lisp condition system is usable for handling error situations, but it's usable for much more as well; the act of signaling a condition does not immediately unwind the stack, like throwing an exception does, and the restart system allows for actively choosing which pieces of dynamically provided code should be run instead of just blindly executing them in order.

This allows for some extra flexibility with regard to how to handle errors, and with regard to how conditions may be used without any unwinding whatsoever.

(Thanks for the props!)

It's hard to appreciate the value of restarts if you haven't seen it fully integrated into the environment like on an old lisp machine. Given any exceptional condition deep down in a program, assuming appropriate restarts are bound, it can pop the debugger and let you choose how to proceed, but handlers can also be bound to handle conditions / invoke restarts programmatically. Restarts may be bound at different layers of granularity so if you had a command operating on a set of files, one one of them fails to open, the avaiable restarts might be "Retry command", "Skip this file", "Retry open", "Provide alternate filename", etc. It's sort of a missing link between interactive and batch/scriptable environments that current operating systems are missing.

(My Common Lisp is getting rusty, sorry if I've slightly jubmled the condition/handler/restart lingo)

Thank you. I am taking a big risk by making the statement in 4.11 (in the online Appendix E), since it directly implies that none of C++, Java, Python et al actually do any exception handling at all. It's all control flow, always has been.

Still, I've actually wanted to write it there since I considered it to be important, and because that argument came into existence during the first Hacker News discussion about the book (and therefore is a product of more than just my mind).

Thanks, hope that it serves you well.

Thank you! I hope that it serves you well.