38 ms·
This is one of my favorite features of Common Lisp programming. The nice thing about interactive restarts is that the whole stack is there... so all of the prev
by agentultra 11y ago
This is one of my favorite features of Common Lisp programming. The nice thing about interactive restarts is that the whole stack is there... so all of the previous functionality is available as discussed previously in the series. You can interactively inspect an object to see what slot values are causing a conflict and not only change the value and continue but recompile the method that caused it as well. And of course clever code could do this as well.
Restarts are a very nice way of handling known error conditions and I wish more languages had stolen this feature from Lisp before macros or garbage collectors and things.
- kazinator 11y agoIt's a good feature for building big programs that have lots of layering. It's not really at the core of the Lisp essence; Lisp dialects other than Common Lisp and some of its ancestors do not have this feature. > I wish more languages had stolen this feature from Lisp The terminology and some of the semantics of CL's condition may have been derived derived from concepts in IBM's PL/I programming language! Similarities: * PL/I's xceptions are called "conditions" in PL/I. * Conditions are "signaled" (by a construct called SIGNAL). * The "on unit" construct (ON statement) resembles condition handling and restarts (functionality of handler-bind and restart-bind rolled into one). On units are dynamically scoped, and when a condition is raised they are searched without discarding the stack ("the whole stack is there", in your words). On units can return to the source of the signal, or execute a GO to the surrounding procedure, which then triggers unwinding: exactly like a (go ..) in Lisp jumping out of a restart lambda. * Conditions in PL/I are used not only for errors but for giving advice to low level code on what to do. For instance the printing system signals an "endpage" condition, and the higher level code can provide an on unit to do what it wants at the end of a page. This on unit returns to the lower level code. I've never written code in PL/I, but I studied the condition system.
- hga 11y agoPL/1 had such an influence. Multics had its own version of it as its system language, which had "on-conditions", which per http://www.multicians.org/pl1-raf.html http://www.multicians.org/pl1-raf.html made optimization difficult. Bernie Greenberg was a major Multics "kernel" hacker, and wrote Multics Emacs in MACLISP and PL/1 before joining Symbolics. Per vague memory and Wikipedia (https://en.wikipedia.org/wiki/Bernard_Greenberg https://en.wikipedia.org/wiki/Bernard_Greenberg): Greenberg was involved in the design of the "New Error System" at Symbolics, which in turn influenced the condition system adopted by ANSI Common Lisp. And per the referenced citation (http://www.nhplace.com/kent/CL/Revision-18.txt http://www.nhplace.com/kent/CL/Revision-18.txt): Many aspects of the NES were inspired by the (PL/1) condition system used by the Honeywell Multics operating system.
- agentultra 11y ago> It's not really at the core of the Lisp essence This isn't the first time this has been pointed out to me. Someone had pointed me to Kent Pitmans'[0] paper on Common Lisp's condition handling system. It is quite a good read. As I wasn't even born when Multics and PL/1 were released and was never old enough when they were around to have used them I do lack that context. To me, having started using CL around 2008, it is an essential "feature" of the Lisp experience. One that no other language I'm aware of implements and few, if any, operating systems implement today. Unix signals perhaps could emulate it? So... my apologies if my ignorance characterizes Lisp incorrectly but I still wish this style of error handling was more common. It is just so damn useful. [0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...