This is Common Lisp on macOS/Cocoa - using WhateverCLIM. I don't know, I thought it was kinda cool.

I've been working on a symbolic processing virtual machine based on S-expressions. Programming instructions resemble a kind of assembly, and the code and data are spanned over a hosting virtual filesystem.

Metaprogramming and basic virtual filesystem operations are at the heart of the system, so it can be suitable to embed arbitrary higher level programming systems, preferably S-expressions based ones.

Since symp practices some properties of the Lisp systems (although approaches the programming problems from a slightly different side), I thought this subreddit might be a suitable place to share this work.

The main intention of symp is to support my symbolic AI experiments, but I reckon I'll find it a use in business programming (at least for some of my own projects).

For now, it can be used in a browser and in Node.js through exposed API.

Resources:

• online demo playground
• github project page

A blog post about hashing numbers under EQUALP in ECL. Some theory, math, microptimizations and (for me) a lot of fun. Contains benchmarks of ECL vs ECL and ECL vs world. Enjoy!

Hi all, I'm the author (in the product sense — see below). ZenLisp is a macOS IDE for Common Lisp built on SBCL. You work in one live image: evaluate a form, click the result to inspect the real object, stop in the debugger, fix the code, and restart the frame that failed.

It's still in active development, not a finished release — I'm posting now because the core is working and feedback on direction is worth more at this stage than later.

What's in it: a REPL where results are live objects (Cmd-click to inspect), a debugger with restarts, backtrace, frame locals and restart-a-frame, compile-as-you-type with warnings marked on the exact symbol (saving compiles only the top-level forms that changed), go-to-definition that checks local bindings first, Trace/Profile panels, macroexpand-in-place, disassembly, a test runner for FiveAM/Parachute/Rove, and a Docs panel with the HyperSpec. Projects are ASDF systems with Quicklisp, qlot, ocicl or vendored deps. The editor has Vim keys, SLIME's Emacs sequences, parinfer and structural editing.

Claude can work in the same image — either the built-in assistant, or Claude Code over MCP (tools include eval, macroexpand, who_calls, invoke_restart, run_tests). Every compiler warning has an "Ask AI to fix" button.

The unusual part: Claude Code wrote all of it — the Rust backend, the TypeScript UI, the Lisp inside SBCL, the tests. I wrote no code; I asked for features, used the app, reported bugs, and made the product calls.

Status: macOS-only, in development, no binary yet — building from source needs Node, Rust and SBCL: https://github.com/eric-zhu-2019/zenlisp — bug reports and "this is what SLIME does that you're missing" are exactly what I'm after.

Also, no relation to Nils M Holm's Zenlisp dialect — this is an IDE, not a language.

I'd especially like to hear from SLIME/Emacs users: what's missing that would stop you trying it?

I've posted about OpenLDK in the past, but would like to share some recent improvements. For instance, you can start up springboot applications running on SBCL in a few 10ths of a second, connect to them with sly/slime, then inspect and monkey-patch the running application by adding :before/:after CLOS methods to the application's java methods.

Clojure, ABCL and more all run on SBCL, and you can even embed them all in a single SBCL form using special reader syntax. Check out this wild example:

(polyglot:startup :verbose nil)
(setf *readtable* (polyglot:enable-syntax (copy-readtable)))

(format t "~&~A~%"
  #@abcl{                                ; ABCL: FORMAT's Roman numerals and English
    (let ((n $#@kt{                      // Kotlin: a local data class, copy, when, ?:
               data class Cup(val tea: Int, val sugar: Int? = null)
               val cup = Cup($#@sc{     // Scala: a list pattern with a guard
                               $#@jscheme{   ; JScheme: digit sums in a named let
                                 (map (lambda (n)
                                        (let loop ((n n) (sum 0))
                                          (if (< n 1)
                                              sum
                                              (loop (quotient n 10) (+ sum (remainder n 10))))))
                                      $#@kawa{   ; Kawa: Java by colon notation; call/cc; exact division
                                        (let* ((m (java.lang.Long:sum
                                                   $#@gv{   // Groovy: the spread-dot operator
                                                     $#[ (->> (iterate inc 2)   ; Clojure: lazy and infinite
                                                              (filter (fn [n] (not-any? #(zero? (rem n %))
                                                                                        (range 2 n))))
                                                              (take 10)) ]*.power(2).sum()
                                                   }
                                                   1))
                                               (d (call-with-current-continuation
                                                    (lambda (found)
                                                      (for-each (lambda (d)
                                                                  (if (not (= 0 (remainder m d))) (found d)))
                                                                '(6 5 4 3 2))
                                                      1)))
                                               (r (/ m d)))
                                          (list (numerator r) (denominator r)))
                                      })
                               } match {
                                 case List(a: Int, b: Int) if a > b => a * b
                                 case List(a: Int, b: Int) => a + b
                               }
                             }).copy(sugar = null)
               when { cup.tea > 40 -> cup.tea + (cup.sugar ?: 1); else -> cup.tea }
             }))
      (format nil "~@R (~R)" n n))
  })

I'm currently working on a quantitative finance library for common lisp (SBCL only). Emphasis is currently placed on pricing options, but more capabilities exist and are planned, such as pricing various interest rate instruments.

In particular, the Monte Carlo simulation engine is showing promise, allowing users to write their own random processes to simulate, and write options on those processes. Against prior art (QuantLib in C++), the Monte Carlo engine benchmarks quite well, with other pricing engines being a mixed bag (a fairly complete suite with results is given in the repo).

Being a lisp project, extensibility is supported and encouraged. While the library provides random processes and instruments seen in quant textbooks, the manual gives a toy example of writing option contracts on a game of dice. Other facets are extensible, such as allowing the user to write their own option payoff schemes.

The repo is here with a small write-up outlining the extension of the Monte Carlo engine with a similar flavor of die game. Everything should be considered work-in-progress.

Hi all,

A while ago I posted here about ggg (Guile Glyph Generator), a small tool I wrote in Guile Scheme that renders shields.io-style badges (SVG, plus PNG on request) from a Scheme config file. Since then it grew quite a bit, so here is what landed — including the packaging news at the end.

The pitch is unchanged: you describe a badge as data, ggg does the geometry.

scheme (define my-badge `((sections ((background . catppuccin-mocha-surface2) (text . "Guile") (color . catppuccin-mocha-text) (logo . scheme-guile)) ((background . catppuccin-mocha-peach) (text . "3.0.10") (color . catppuccin-mocha-base))) (id . scheme-guile-3) (style . shadow)))

Links

• Source (Codeberg): https://codeberg.org/jjba23/ggg
• Gallery of every badge, color and logo: https://jointhefreeworld.org/ggg/dist/gallery.html
• Technical API docs: https://jointhefreeworld.org/api-docs/ggg/API.html

How to run

Run ggg -f my-glyphs.scm -d ./dist and you get scheme-guile-3.svg (and .png with -c). The geometry follows the badges GitHub shows — 20px tall, 11px text, a 14px logo, 5px side padding, 3px corners — drawn ~9% larger so it reads well next to body text, with per-character text width estimation so the badge stays as tight as the ones in README files. What comes out is a real vector file, not a raster wrapped in SVG.

What's new since the last post

8 badge styles. A glyph can now ask for a finish: flat (default), square, shadow, plastic, frosted-glass, material, frutiger and neon. Styles only decorate — canvas, width and height are identical to flat, so a row of badges that mix styles always lines up. Glosses, glows and shadows are painted inside the badge, never around it.

scheme (id . scheme-guile-neon) (style . neon)

12 color themes, 236 named colors. Instead of hex codes you write catppuccin-mocha-red, dracula-purple, solarized-light-base3, modus-vivendi-green, doom-one-blue… Every color of Catppuccin (mocha, macchiato, frappé, latte), Doom (one, one-light), Dracula (and alucard), Solarized (dark, light) and Modus (operandi, vivendi) is available by name. ggg --list-colors prints them; raw hex strings still work and are validated.

Because the palettes span light pastels to deep shades, the ink has to follow the background — so the test suite enforces at least 4.5:1 contrast (WCAG AA) on every section of the shipped glyph files. A badge with unreadable text fails maak test.

A gallery you can actually browse. ggg --gallery gallery.html --glyphs ./glyphs writes a single self-contained HTML page with every badge at its real size, every logo inlined with the snippet to use it, and every named color of every theme as a swatch. Click a snippet or a swatch to copy it. The deployed one is here: https://jointhefreeworld.org/ggg/dist/gallery.html

284 logos, as full SVG documents. Logos used to be a single path's d attribute. They are now complete <svg> elements, so a logo can carry multiple paths, groups, gradients, transforms or filters; ggg only needs a viewBox and does the scaling and placement. The library covers languages, frameworks, databases, distros, editors, shells, CI, cloud, observability and more — mostly from Simple Icons (CC0), plus hand-drawn ones. CREDITS.org lists the source and license of every single file, and names the brand marks that were deliberately left out because their upstream license isn't a free one.

Badges with any number of sections. Not just two or three parts — each section becomes a segment with its own text, background and color, and the badge grows to fit. The logo belongs to the first section.

Validation before anything is written. ggg checks the whole glyph file first and reports every problem with a hint: unknown color, logo or style names (with a "did you mean" suggestion), a missing text, sections without colors, (key value) written where (key . value) was meant, duplicate glyph ids, and the legacy resources/svg-paths/ directory if it finds one. If the file is invalid, nothing is written to the destination directory at all.

Smaller things: --version, --list-colors, --list-logos, --list-styles, -k/--keep to render a second glyph file into a directory without clearing it, a new ggg mark, and a test suite (122 checks) covering color resolution, the logo library, glyph validation and the gallery.

Packaging

• GNU Guix — ggg has been in Guix for a while; I sent the update PRs to 0.16.1.
• Nix — new. There is a default.nix and a flake.nix in the repo, and I sent the pkgs/by-name/gg/ggg/package.nix addition to nixpkgs (that one runs the whole test suite in checkPhase). Both builds render all 177 showcase badges.
• Debian, openSUSE, Arch — packaging for all three now lives in packaging/, installing the same layout (/usr/bin/ggg, modules under Guile's site directory, help text and logo library under /usr/share/ggg/resources). Built and installed in debian:trixie, opensuse/tumbleweed and archlinux containers.
• Container image — docker.io/jjba23/ggg (Podman works too).
• Version numbers now live in exactly one place (src/ggg/version.scm), and maak release writes them into guix.scm, commits and tags.

Try it

```shell

Guix

guix shell -f guix.scm -- ggg --gallery ./gallery.html --glyphs ./glyphs

Nix

nix-build default.nix && ./result/bin/ggg --list-styles

Podman/Docker

podman run --rm -v "$PWD:/work" -w /work docker.io/jjba23/ggg:latest \ ggg -f ./glyphs/showcase.scm -d ./dist ```

Notes on licensing

ggg itself is AGPL-3.0-or-later and the docs are FDL-1.3+. The tool claims no ownership over what it generates: the badges you produce are yours, no attribution or license conditions attached, and the logo library keeps its own licenses (listed per file in CREDITS.org). So if you want a badge that is completely free of third-party terms, use no logo or your own.

Feedback very welcome — especially which styles, themes or logos are missing, and what a badge generator would have to do for you to actually use it instead of a static PNG. I'm also happy to take packaging help for distros I don't run.

qlp turns a directory of local Common Lisp projects into a Quicklisp distribution: distinfo,
releases.txt, systems.txt and one reproducible archive per project.

qlp publish --name mydist --base-url https://dist.example.org \
--projects-dir ~/lisp/projects --dists-dir /srv/www/dist

Write-up on lisper.nl
Source on GitHub

It is a modern quickdist, with one difference: quickdist reads .asd files textually, so systems
declared through a macro never reach systems.txt. qlp reads them the way ASDF does, so they are
published too.

I’ve completed a new scheme R7RS-small compiler with optional JIT support . It is written purely in rust and has a rust api for embedding in rust programs but also has a standalone repl ( with completion, history etc ) . There is an included eMacs package that supports a small subset of slime behavior via tcp.

The disclaimer is that this was written using agentic programming ( fable and opus ) over a one week period. My project is a new rendering and modeling system but I needed an embedded language with specific requirements so I chose scheme after evaluation of 5 or 6 alternatives.

It mainly has been tested on macOS but should run on Linux . ( I’ll do more Linux testing as I get time )

github.com/k2msmith-gfx/scm

Hey everyone, I’m Lucas and I would like to talk about a project that my brother and I have been working on.

We’ve been enjoying writing in Common Lisp since we started learning it a few years ago. We think it’s a great language and we're surprised it’s not more widely used.

With that said, we were having trouble getting deeper into it because the available editors are not like what we were used to with other languages. We’ve always enjoyed the JetBrains’ editors, unfortunately we did not find something like them for Common Lisp. So we decided to build our own. We’ve called it Lispcraft.

It isn’t as feature-rich as Emacs, but its features are easy to use. That's why we wrote it in the first place: to provide an easy-to-use, modern editor experience.

We wrote our own GUI without using toolkits. Instead, we used OpenGL; it's very fast and smooth. Because we had trouble configuring everything in other editors, we made everything bundled, including SBCL and Quicklisp.

It's REPL-first. You can always execute the form under the cursor by CTRL + ENTER. Also, you can inspect objects' slots by clicking on the REPL output.

Indentation is powered by a custom engine. Syntax highlighting is semantic. It has jump to definition, callers, hover docs, autocomplete, and project-wide search.

It's an MVP, so there will be bugs. For now, it's x86-64 Linux only.

Also, we're aware that Emacs users will not switch to this editor; the user we have in mind is someone who is used to modern editors in other languages and tried to write in Lisp but disliked the tooling difficulty.

Link to the site/video: https://lispcraft.com - we will keep an eye on this post to hear your thoughts!

We're planning to fix bugs, port it to macOS and Windows, and copy good features from other editors. Also we are planning to release a local host FIM ai trained on Common Lisp corpus. That's why I'll charge $19 / month to fund it.

Spent the week reading about coding agents and now I see lisp everywhere. Half the features these harnesses brag about are things a lisp image just does:

• agent writes its own extension and loads it without a restart -> that's a live image
• "ask the agent to change the agent" -> redefine the function, M-x style
• hooks around every step of the loop -> advice
• poke at the running agent and inspect its state -> that's a REPL, they built a REPL

Saw someone make the Greenspun's tenth rule argument about Pi this week, plus an Erlang version of the same complaint

What I haven't seen anyone copy yet is the condition system, and it's the one agents need most. today when a tool call fails the agent either throws everything away and retries, or freezes and waits for you. CL restarts fix exactly that. signal the error, let you) choose "retry with a fix" or "skip this one", and keep going from the samespot with the stack still intact. my guess is someone ships it in TS next year and calls it "recoverable checkpoints"

something like this:

(defun run-tool (call)

(restart-case (execute-tool call)

(retry-with (new-call)

:report "Retry with a corrected call"

(run-tool new-call))

(skip-call ()

:report "Skip this tool call"

nil)))

(handler-bind ((tool-error

(lambda (c)

(invoke-restart 'retry-with (ask-model-for-fix c)))))

(run-agent task))

replace ask-model-for-fix with a prompt to the user and you're basically back amenu, which is honestly what I want every time an agent gets stuck.

what else do you think they'll reinvent, and badly?

Source / issues / patches: https://codeberg.org/jjba23/byggsteg

• A pipeline is a list of Lisp. A job is a lambda returning an alist (project, branch-name, clone-url, task). Return a list of those and you get stages: run in order, one log, one status, first failure stops the rest.
• Tasks for the usual moves — maak-test, make-build, maak-deploy, pull-and-restart (git pull + GNU Shepherd restart), byggsteg-version — plus trivial, where you pass the raw shell commands yourself.
• Logs that arrive while the job runs. Output is read line by line, written into the log in batches, and the page fills up live. ANSI colour is rendered like a terminal would, and each command is announced with → running command: ….
• Artifacts as paths or named bundles, packed into tarballs whether the job passed or failed.
• Retries with a history. A retry is a run of its own with its own log, so the original keeps saying what it said.
• Profiles — a saved job you can run again with one button.
• Activity heatmap (a year of runs, one square per day) and one search over jobs, logs and profiles.
• A real permission model: 7 permissions in an ACL, cookie sessions for browsers, token header for scripts, password resets, 4 languages (EN/NL/ES/JA), retention that prunes log + run + tarballs together.
• REST API v2 described by an OpenAPI document the deployment serves itself; /api/v1 is still there so old scripts don't break.
• Woodpecker bridge if you want to adopt it gradually.

byggsteg (Norwegian for "build step") is a CI/CD orchestrator I've been building in Guile Scheme. One process, one SQLite file, no broker, no job server — and the pipeline is just Lisp.

The GIF is a tour of the new console: dark theme first, then the job types a pipeline can ask for, the runs behind a deployment, one run opened on its log / on the output as it arrived / on the Lisp that asked for it, a year of runs week by week, a search, the saved profiles, the about page and the sign-in.

The new look

• Dark is a phosphor screen: near-black ground, green as the signal (prompt, headings, links, status), soft grey for prose — no pure black or white anywhere.
• Light is a printed circuit diagram: green ink on paper, the same terminal.
• Monospace (Intel One Mono), square corners, keyboard friendly, three colours carry status: green = passed, blue = running, red = failed.
• Fonts, icons and CSS are served by the deployment itself. No Google Fonts, no icon CDN, no third-party requests — it looks the same on an air-gapped box, and opening your private build server doesn't phone two strangers.

Links

• Live instance (read-only without an account): https://byggsteg.jointhefreeworld.org
• Manual: https://jointhefreeworld.org/manuals/byggsteg/
• Roadmap board: https://lucidplan.jointhefreeworld.org/tickets/byggsteg
• Woodpecker integration: https://codeberg.org/jjba23/byggsteg-woodpecker

AGPLv3, documentation FDL. Happy to answer anything — and I'd genuinely like feedback on what a CI console should show while a job is running, that's the part I keep redesigning.

Firstly, thanks to the mods for allowing me to post this.

I've been building Eta, a Lisp-inspired language with its own bytecode VM. I'm not claiming conformance to any particular Lisp standard, but it has a substantial Lisp-style language and runtime.

One thing I'm exploring is what becomes possible when capabilities like automatic differentiation and logic programming are supported directly by the runtime.

For example, with reverse-mode automatic differentiation, the VM provides tape operations, while the gradient function itself is written in Eta. This lets the same grad function work with different user-defined functions, such as a Black–Scholes option-pricing function, without requiring a separate gradient implementation for each one.

I've taken a similar approach to logic programming: the VM supports logic variables, unification, and backtracking.

Eta also supports native libraries through a sidecar mechanism, and I've added libraries for constraint logic programming, causal inference, and actors.

The language is still early, but it already has a compiler, REPL, VS Code extension, language server, debug adapter, linter, formatter, and Jupyter integration.

There are still plenty of rough edges. The GC is currently a simple stop-the-world collector, and numerical performance has room for improvement. However, I deliberately prioritised building a proper development environment early on.

Years ago, I worked with Scala, and one frustration was that, even when a language itself was excellent, tooling could sometimes feel like an afterthought. I wanted Eta to have a decent development experience from the outset.

I'm particularly interested in feedback from people who've built languages, VMs, Lisp systems, or logic programming runtimes.

• Is VM-level support for these capabilities worthwhile, or would you keep them in libraries or implement them entirely at the language level?
• My intuition is that there's an interesting intersection of ML, logic, symbolic reasoning, and causal inference problems that could benefit from a Lisp-style language with a VM designed to support them. Does that seem like a useful direction?
• Does combining these ideas seem useful to anyone else, or would you focus on a smaller core first?

I'm not claiming to have solved these problems. I'd genuinely like to hear what others would challenge or do differently.

Docs: https://lewismj.github.io/eta/

Source: https://github.com/lewismj/eta

The cLogos project is currently taking a break from implementation development to document the project's conceptual and design foundations in a wiki.

One part of this effort is a chronicle of Logo's history and its wider historical context, covering developments that I consider relevant to understanding Logo's origins and evolution.

I'd be grateful if anyone interested in Logo, programming languages, or the history of computing would take a look. Corrections, suggestions for missing connections, and other critical remarks are very welcome!

I’ve been building the Common Lisp programming environment I want to work in, and I’d love some help testing it.

It’s called Turbo Lisp (based on SBCL). It brings together a Listener, debugger, object inspector, conditional breakpoints + stepper, and Zeta—an extensible editor in the Emacs tradition, written in Common Lisp.

On macOS, it uses native AppKit UI through Chattanooga, a Lisp/Objective-C bridge I built. It also runs in the terminal through Oak Ridge, my Lisp port of Ratatui. Both use WhateverCLIM, which is the CLIM2 code from Franz plus my own modernization, including presentations: displayed Lisp objects you can click and inspect.

Rather than write a wall of text, here are two short, captioned demos (you may need to switch to 1080p on YouTube):

• Native macOS: encounter a bug, find its source, and repair the running program
• Terminal: debugger recovery, inspecting objects, and editing pixel graphics—did you even know terminals could do that?

v0.2.1 patch release is available for Apple Silicon Macs, Intel Macs, and Linux x86-64. The Mac builds currently require macOS 26.

I’m especially interested in hearing:

• Does it install and start properly on your machine?
• Can you find your way around the Listener, editor, and debugger?
• Does the terminal interface work with your terminal emulator?
• Where does it feel confusing, awkward, or broken?

You don’t need to be a CLIM expert. A report that says “I tried this and got stuck here” is useful. Please include your OS, CPU architecture, and terminal emulator where relevant.

It’s still early, and I’m looking for honest feedback from people using it outside my own setup.

Source, README, and downloads

# UK Racket meet-up (London) Tuesday 20 October 2026

7:30pm at The City Pride 🍕 28 Farringdon Ln, London EC1R 3AU

Join us for discussion and pizza. All welcome.😁
From November we will be doing short talks and demos!

https://racket.discourse.group/t/uk-racket-meet-up-london-tuesday-20-october-2026-7-30pm/4430

https://luma.com/em6sejij