Mastodawn

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

Kent Pitman Apr 19

@screwlisp

You can pick up the document 'Signalling and Handling Conditions' from this index page:

http://nhplace.com/kent/ZL/

It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.

In spirit, it was much the same. The biggest differences are:

* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').

* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.

* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.

* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.

* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.

There are other differences as well.

#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers

Show thread

screwlisp Apr 14

@vnikolov @kentpitman @dougmerritt @khinsen @holdenweb

This conversation has grown wonderfully and beyond my imagined scope, but I wrote a second example of how I was thinking about it:

https://lispy-gopher-show.itch.io/lispmoo2/devlog/1488992/small-and-beautiful-common-lisp-conditions-like-unix-piping #commonLisp #programming #conditionHandling #scripting

in which I say

$ xargs cat <<"EOG" \
> | cut -d' ' -f2 \
> | xargs -d' ' echo
> foo.tsv
> EOG

and

the following lisp are similar in a number of ways.

Small and beautiful common lisp conditions like unix piping - lispmoo2 by screwtape

When I say I think the common lisp condition system is similar to unix pipes, for example, I mean that I think writing CL-USER> (handler-bind ((a-need-for-read #'read-times)) (handler-bind ((a-need-fo...

itch.io

screwlisp Apr 12

#commonLisp #conditionHandling #programming #example
https://lispy-gopher-show.itch.io/lispmoo2/devlog/1487350/iterating-grandfather-clock-using-ansi-common-lisp-conditions-as-such

The gist is a clock that chimes (cuckoos, here, I guess) harnessing the power of conditions.

I think this sm0l article indicates that ansi common lisp condition handling is a more powerful expression of but similar to unix pipes; look at what modifying the handlers does and is like in the article.

SADLY I am not available for the #lispyGopherClimate sundaymorningineurope.

An appointment was made without asking me.

Iterating grandfather clock using ansi common lisp conditions as such - lispmoo2 by screwtape

As the premise, let us imagine programming up a clock that is going to chime twelve times at midnight. In this sm0l article, I am just going to try the common lisp condition system as such. Later, I w...

itch.io

screwlisp Mar 9

#itchio #programming style #devlog #conditionHandling #commonLisp #reliability #softwareEngineering

https://lispy-gopher-show.itch.io/leonardo-calculus/devlog/1453593/a-little-ansi-common-lisp-condition-ls-example

Finally pretty happy with my "programming ls" example. This is a good programming with conditions first blush, I think.

Programming with signals and restarts that a run-time handler-bind hooks into gives a program, such as my %%ls here, *forward compatibility* not just *backwards compatibility* - which I explore as a property of ansi common lisp itself.

Thoughts!

screwlisp Feb 28

https://screwlisp.small-web.org/conditions/partial-gopher-client/

#commonLisp #conditionHandling implemented as a #gopher protocol using #emacs #slime as the client.

This is even better than it sounds.

The condition handling system (nonfatal generalization of exception handling using lisp's local restarts/continuations) is unexplored and seen as opaque.

Using this tiny but esoteric example the available non-lexical computed restarts of an interactive condition are simply /browsable/.

#programming #softwareEngineering

Coincidentally, I assume, Abhijit Rao posted on LinkedIn earlier today a very interesting blurb, reporting on his use of this condition handling structure in conjunction with LLMs.

(Works for me in an incognito window, but you may not be able to see past the first comment if you don't have a LinkedIn account.)

https://www.linkedin.com/posts/quasiabhi_commonlisp-lisp-agents-activity-7425847332560293888-fYf9

The blurb references this more detailed account of the work, which I haven't been through in detail yet:

https://quasilabs.in/blog/2026/02/07/conditions-restarts-and-the-agent-that-chooses/

#CommonLisp #Lisp #ConditionHandling #Errors #Restarts #Continuations #ErrorHandling #ConditionHandling #LLM #LLMs #AI #Modularity #QuasiLabs #Reflection #Introspection #MetaProgramming

#commonlisp #lisp #agents #llm #programming #code #quasilabs | Abhijit Rao

In 1988 The Common Lisp Condition System was formally introduced by the X3J13 committee, responsible for the ANSI standard. It was a radical idea: The code that /detects/ an error should not decide how to /recover/ from it. Instead, the signaler establishes named recovery options—restarts—and lets a handler higher up the stack choose which one to invoke. The decision belongs to whoever has the broader context. This was ahead of its time. For 35+ years, the "broader context" was either a human in the debugger or a programmer who knew at compile time which restart to pick. Both worked fine. Then LLMs showed up. An agent monitoring a data pipeline encounters a validation error. Three restarts available. No hardcoded strategy. The agent needs to reason about system goals, weigh tradeoffs, adapt to context it wasn't explicitly programmed for. The architecture was already right. What was missing: semantic context for the handler. Restarts come with names and descriptions. Agents need to know what the system is /trying to achieve/. What failed and why. What each recovery option costs. Why these specific restarts exist in the first place. When you add structured intent metadata—goals, failure modes, design rationale—the agent can map recovery options to system objectives. Same restarts. Profoundly different decision-making surface. I built Telos to capture this. It makes the why behind code queryable at runtime. Combined with conditions and restarts, you get agent-legible error recovery. The condition/restart protocol already separates mechanism from policy. It supports multiple recovery options without the signaler knowing which will be chosen. It allows the handler to be arbitrarily far—in code, in time, in understanding—from the signaler. It's an architecture perfect for agentic systems. And, yes, Common Lisp has an ANSI standard. Blog post with full working CSV validator example: https://lnkd.in/dSbuDK6J #commonlisp #lisp #agents #llm #programming #code #quasilabs