Over the last few years I've been occasionally testing Gemini's ability to write Dylan code. Dylan has such a small user community and code base I'm not usually surprised at the results.

That said, it has progressed quite a lot since a few years ago from "Dylan is basically Python, right?" (nope) to "here's some base64 Dylan code that is almost correct". Yesterday I asked it to convert this CL macro

(defmacro inc! (place) `(setf ,place (+ 1 ,place)))

to Dylan and was fully expecting it to generate a mess. Instead it did it perfectly (see image).

#DylanLang #CommonLisp

(I post this with some trepidation because I know AI generates a lot of strong feelings. I don't really want to get into that debate and I'll just say this is the only way I've used AI at all, just as a curiosity in relation to my Dylan hobby.)

Made a little "redirectory" for looking up items in the Dylan Reference Manual (DRM). For example, to lookup <object> go to https://drm.opendylan.org/<object> (which Mastodon fails to link correctly). To look up "for" use https://drm.opendylan.org/for etc.

Slightly quicker than using the DRM index. This is just done as a bunch of nginx config redirects.

(I notice that in macOS Firefox I get 404 the first time I try for a given name but it works on the second try. Chrome seems fine. Is this because 308 redirects are "new" maybe? 🤔 )

#DylanLang

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

Got VS Code colorization for Dylan in pretty good shape. Now to work on a theme that is less "fruit salad" and more "where are the important bits".

#DylanLang #vscode

@hajovonta @simon_brooke

(reduce #'eq '(x x x)) -> NIL

You really have to do something like

(reduce (lambda (a b) (and (eq a b) a)) args)

which fails for `(nil nil nil), or better

(every (lambda (a) (eq a (car args))) (rest args))

Both are a little annoying. I prefer n-ary functions.

That said, #DylanLang makes all of the comparison functions binary and I don't remember ever needing an n-ary version. But if there's no performance penalty I say go for it.

🎉 Release 2026.1 of the Open Dylan compiler, IDE, and tools is available for download!

This release includes several performance enhancements for the runtime and generated code, along with the usual bug fixes.

See the 2026.1 release notes for an overview of what's in this release: https://opendylan.org/release-notes/2026.1.html

Download here: https://opendylan.org/download/index.html

#OpenDylan #DylanLang #compiler

🎉 Just released a new version of DIME, the #DylanLang Emacs IDE! Bug fixes, new doc, some reorg.

Supports
- jump to definition
- edit callers
- parameter list display
- compile buffer project
- jump to compiler warnings
and more.

https://github.com/dylan-lang/dylan-emacs-support/releases/tag/v0.2.0

https://package.opendylan.org/dylan-emacs-support/index.html