Going to include the common lisp condition system in the comparison?
I can never get past the ugly syntax.
Standard exception handling is:
- Whenever an error happens, the program puts a description of it into an “exception” object. You go from the innermost dynamic scope to the outermost looking for handlers. Once you find a handler willing to accept that type of exception, you unwind to the point where it was installed then invoke it, passing the exception object.
Condition handling[3] is:
- Whenever an error happens, the program puts a description of it into a “condition” object. You go from the innermost dynamic scope to the outermost looking for handlers. Once you find a condition handler willing to accept that type of condition, you invoke it as a regular callback, without unwinding, passing the condition object.
- The handler then packs up some data into a “restart” object. You go through all the dynamic scopes again (remember that the erroring function is still active). Once you find a restart handling willing to accept this type of restart, you unwind to the point where it was installed then invoke it, passing the restart object.
(I am omitting things outside the happy path: a way for the exception/condition handler to punt, what happens if the condition handler does not invoke a restart, etc.)
As far as the benefits of this two-phase approach, Practical Common Lisp gives an example[4] of a single-record parser that raises an “invalid record” condition, a loop around it that installs a “skip to next record” restart, and finally the caller can make the policy decision on what to do for invalid records.
As another example, Common Lisp signals an “unbound-variable”[5] condition leaving the “use-value” and “store-value” restarts in scope, then the REPL installs a handler that offers them interactively. (My own half-serious example of a DOS abort/retry/fail prompt is in this vein too, chosen mostly because it feels strange that you can’t do it in a conventional exception system.)
[1] https://package.opendylan.org/dylan-programming-book/excepti...
[2] https://news.ycombinator.com/item?id=31196046
[3] https://www.nhplace.com/kent/Papers/Condition-Handling-2001....
[4] https://gigamonkeys.com/book/beyond-exception-handling-condi...
[5] https://www.lispworks.com/documentation/HyperSpec/Body/e_unb...
But the "I can never get past the ugly syntax." reason is unusually superficial from you. Understanding Lisp macros or CLOS (the very cool object system) or Conditions (which are like exceptions, but also different in a very interesting and powerful way) is totally worth enduring the syntax for a language designer.
If you find the time, give it a try! Either way: I am a big D fan, so I agree with your tastes most of the time. Thanks for your work :)
I find the ((()))) aspect of it difficult to read, whereas the algebraic notation is easy. I've struggled with trying to read Lisp code for decades. It's a proverbial square peg that won't fit in the round hole.
A major aspect of D is the aesthetic look of the code. It's why I call D "elegant" as it just looks good on the screen. For example, this is how modules are imported:
import foo;