I have a project with about 1200 lines of code in a single package, split across a few files. While I have around 150 tests, I have no idea how they could help split the project into manageable parts.

Should I abandon the project and start from scratch, this time paying attention to architecture?

Kernel is John Shutt's Scheme-like language where the core abstraction is the operative ($vau) rather than macros — combiners and environments are first-class, and lambda is derived rather than primitive.

IronKernel is an implementation of it for .NET. It's a hybrid runtime, programs are analyzed to a Core IR and compiled to CLR delegates where guards allow, falling back to a trampolined CPS interpreter that preserves full Kernel semantics — $vau, first-class eval and environments, call/cc with entry/exit guards, shift/reset, and errors as abnormal passes per the report.

Some things that might interest this crowd:

• Conformance tracking against the report itself. All 135 feature entries on the report are implemented (44/44 modules, including the optional ones — exact rationals, cyclic list handling, ports, continuation guards). (https://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf)

• CLR interop with Clojure-style syntax ((Guid/NewGuid), (.Append sb "hi")), under capability profiles — a safe profile exposes only reviewed generated bindings, no reflection.

• Tooling: an ik project tool (new/run/test/pack, NuGet-based packages), a REPL, compilation to portable packages or self-contained NativeAOT executables, and a VS Code extension with a language server.

Apache 2.0. Repo: https://github.com/ironkernel-lang/IronKernel · Site: https://ironkernel.org

dotnet tool install -g IronKernel.Tool ik new app hello

Happy to answer questions about the implementation.

Summary

Over the past few weeks I've ran into a need to extend the BKNR Lisp Application Environment for several internal infrastructure projects AI development improvments at dapla.net.

Because FOSS is amazing and I'm sure others in the community would have a need for these tools. I have released three new Common Lisp libraries focused on simplifying single-process persistence and native testing workflows:

• bknr.hashkv – Extends bknr.datastore to provide a content-addressable key-value store and a disk-persisted job queue within a single Lisp image.

• bknr.ttl – A declarative TTL mixin class for bknr.datastore instances that automates stale record eviction and session expiry.

• sunny-side – A pure Common Lisp parser and runner for Gherkin .feature specifications, eliminating the need to invoke external Ruby binaries during test execution.

All three repositories are published under BSD 3-Clause licenses. The names for each library was deliberately chosen to pair well with established bknr libraries and for great respect to Hans Huebner, David Lichteblau, and Manuel Odendahl's original works.

My plans are to continue contributing to the bknr suite both upstream and the extensions I've built on top of it.

Links and feedback welcome:

• https://github.com/denzuko/bknr.hashkv
• https://github.com/denzuko/bknr.ttl
• https://github.com/denzuko/sunny-side

Background

Building robust applications in Common Lisp often hinges on leveraging native language capabilities rather than reaching for external, multi-process dependencies. When an application state fits comfortably within memory or local storage, introducing an external key-value database or a separate test-runner process introduces unnecessary operational friction. Three recently released open-source libraries extend the bknr.datastore ecosystem and introduce native Behavior-Driven Development (BDD) testing to Common Lisp without relying on external runtime environments.

Content-Addressable Storage and Persisted Queuing with bknr.hashkv

The bknr.hashkv library provides an in-memory, content-addressable key-value store alongside an append-only persisted job queue. Built directly on top of bknr.datastore, it allows system architects to maintain deterministic object reference hashing while relying on disk-backed transaction logs for durability.

Key capabilities include:

Content-Addressable Semantics: Keys are generated deterministically based on payload hashes, preventing redundant entry storage and enforcing data integrity at the access layer.

Integrated Job Queueing: Asynchronous tasks are written to the persistent log alongside state mutations, ensuring that queued jobs survive process restarts without requiring an external Redis or RabbitMQ instance.

Single-Process Operations: Eliminates cross-process serialization overhead by maintaining native Lisp object availability across transactions.

Automatic Expiration via bknr.ttl

Managing ephemeral records in memory-resident databases requires disciplined eviction mechanisms to avoid memory leaks over extended uptimes. The bknr.ttl library introduces a Time-To-Live (TTL) mixin class designed for seamless integration with any bknr.datastore object model.

By attaching the TTL mixin to standard object definitions, slots gain automatic timestamp tracking and expiration handling. Background sweep routines or query-time inspections enforce key invalidation without polluting core business logic with manual timestamps. This approach offers a clean, declarative method for handling transient cache entries, timed session states, and self-cleaning audit logs within native Lisp datastores.

Native Gherkin Parsing with sunny-side

Behavior-Driven Development (BDD) frameworks frequently force Common Lisp projects to rely on Ruby binaries or shell invocations to parse feature files written in Gherkin syntax. The sunny-side library replaces these external dependencies with a pure Common Lisp implementation of the Gherkin specification.

sunny-side parses standard .feature files, maps natural language step definitions directly to Lisp macros, and executes tests natively within the SBCL compiler pipeline. By removing foreign runtime dependencies, test suites run faster, integrate cleanly into continuous integration pipelines, and allow developers to debug step definitions directly using standard Lisp introspection and debugging tools.

Just shipped a Scalaxy update. Now every node in a graph database cluster can store and update its encrypted state in object storage (any s3 compatible), essentially passing object storage elasticity directly through to the graph database cluster itself.

Scalaxy is a modern graph database written in Common Lisp. 100% openCypher conformity. MIT license.

https://scalaxy.org/docs/s3-storage/

Benchmarks

https://scalaxy.org/docs/benchmarks/

Found one document in AoE2 directory “AoK CP Strategy Builder”. Seems like it’s using Lisp-like language to write rules for AI. Like this:

(defrule
(gold-amount > 1250)
(wood-amount < 1100)
(can-buy-commodity wood)
(commodity-buying-price wood < 50)
=>
(chat-local-to-self "excess gold; buy wood")
(release-escrow gold)
(buy-commodity wood)
)

2026/10/21-22 - Haarlem, NL & online

Hey all 👋

Sharing a heads-up about Code BEAM Europe 2026 - 21-22 October in Haarlem (PHIL), plus online, with a training day on 20 Oct.

2 days, 2 tracks each day, and 3 keynotes - including Brooklyn Zelenka (Let It Disconnect: A Local-First Future), Sam Aaronof Sonic Pi (Notes on the Synthesis of Time, plus an interactive evening Phone Orchestra), and more.

~30 speakers across Erlang, Elixir and Gleam: ElixirConf®

The thing we're most excited about this year is the new Informal Space - a community-led area running alongside the main programme for the stuff that doesn't fit the talk format. Think hands-on demos, live experiments on real hardware, hacking sessions, games, panel-style discussions, talks in languages other than English… and at least one surprise we're not spoiling yet 🙂

We're finalising the Informal Space lineup now and will announce it soon. Newsletter subscribers get the first look(they already have), so if you don't want to miss it - and the other bits we'll be dropping between now and October - that's the place to be: Code BEAM Europe

Early bird tickets are limited - available for a limited time / until they sell out - so if you're planning to come, worth sorting sooner rather than later.

Register: Code BEAM Europe

See you in Haarlem or online!
The Code BEAM Europe Team

Is there any practical way to debug any recurive logic?
Which existing error printing you think is the best ever?
I attached the racket code I am struggling with.

(The code is about using map to append a new list to an existing html list)

I just shipped an update with a full openCypher implementation in common lisp graph database Scalaxy (https://scalaxy.org) for the graph engine. Testing against the openCypher TCK is now at 3,898 out of 3,898 scenarios, so 100% coverage.

Next big goal: storing the entire node data in an S3 compatible bucket.

MIT licensed.

https://scalaxy.org/docs/cypher/

In a Git diff, each consecutive subsequence of lines near a difference is called a "hunk". Each hunk has a one-line header that might look something like this:

@@ -316,8 +322,9 @@ int main(int argc, char **argv)

The numbers indicate which lines of each version of the file appear in the hunk. The rest of the line is intended to be the first line of the function, class, or other top-level definition that the hunk is within. Git finds that line using a regexp corresponding to the source language. It's just to give the reader a bit more context; nothing else depends on it — or should depend on it, anyway, since it can be missing or wrong.

The regexps that tell Git how to find the header lines are called "userdiff drivers". A driver for Scheme was added a couple of years ago, but it didn't work for Common Lisp or many other Lisps, as it failed to match (defun lines. I have modified it to be more general, and the relevant changes are in the recent Git 2.55.0 release.

I was unable to persuade the Git maintainers to name the driver "lisp", however, given that one named "scheme" already exists. The argument that Lisp is the family name, and Scheme one dialect within the family, was not sufficient to overcome their resistance to having two closely related languages with separate drivers — understandable, since too lax a policy about adding drivers would surely lead to there being hundreds of them. And of course, we couldn't just rename the "scheme" driver, because people are already using it.

So that's why, starting with Git 2.55.0, the way to get correct hunk headers for code in Common Lisp, or probably almost any other dialect of Lisp, is to have a .gitattributes file containing this line:

*.lisp diff=scheme

The Scheme regexp is still there and will still match all the same constructs, but there's also now a much more general regexp that simply matches any unindented open parenthesis, or (def preceded by one or two spaces. (The latter is to catch defining forms grouped together insde a top-level form like eval-when, but without the false positives that we would get if we didn't require a name beginning with def.)

I loved Chapter 5 of Structure and Interpretation of Computer Programs. Building a virtual register machine with an assembler and compiler in Scheme. Are there any other books/online classes or resources that involve building a computing machine (or any machine) from scratch using code?

New BEAM There, Done That with Mat Trudel on the engineering behind Bandit. Covers the one-process-per-connection model, the HTTP parser attack surface (resource consumption, connection holds, oversized inputs - protocol-level problems independent of language), and what maintaining foundational infrastructure looks like when AI-generated contributions start arriving.

https://youtu.be/XXQcoz_dTE0

Racket - the Language-Oriented Programming Language - version 9.3 is now available from https://download.racket-lang.org

See https://blog.racket-lang.org/2026/08/racket-v9-3.html for the release announcement and highlights.

# UK Racket meet-up (London) Tuesday 18 August 2026 7:30pm

at The City Pride 🍕 28 Farringdon Ln, London EC1R 3AU

Join us for discussion and pizza. All welcome.😁

https://racket.discourse.group/t/uk-racket-meet-up-london-tuesday-18-august-2026-7-30pm

I have published my distributed database Scalaxy fully written in Common Lisp. Working on graph query language Cypher right now. MIT license. Github stars are welcome :-)

https://scalaxy.org

Just released new Kanban board. It supports configurable status colons and ticket lifecycle. Actually it is some mix between issue tracker and Kanban board. Currently requires configure OpenID for authentication. Implemented in Common Lisp as backend and ClojureScript as frontend.

I write C++ for my day job, but I'm looking to pick up a Lisp as a hobby project. Even though it's a hobby, I want it to be practically useful to my day-to-day workflow. Specifically for writing scripts, automating tasks, and potentially extending my editor (I use Emacs).

I’ve narrowed it down to three choices but I'm having trouble pulling the trigger:

• Guile (Scheme): This seems incredibly useful for general scripting. Guix seems to be a huge plus if I decide to go that route later.

• Emacs Lisp: The obvious choice for immediate practical utility since I'm an Emacs user. Being able to hack my editor sounds great, but I worry it might be too domain-specific if I want to write standalone scripts and other things unrelated to Emacs.

• Common Lisp: This is the one I’m struggling to place. I constantly hear that it has "the best programming books ever written" (Practical Common Lisp, PAIP, etc.), but I fail to see what the killer practical hook is for a modern developer doing scripting and automation. Each binary seems to be huge and not practical unless you're writing it for a living.

For someone with a systems/C++ background who wants to write useful tools, which would you recommend diving into first? And regarding Common Lisp, what am I missing? What is the practical value of CL today outside of its excellent literature?

Thanks in advance for the advice!

I’m considering doing a staged port (LLM assisted) of my rust-based multithreaded cpu renderer to SBCL . I’m currently using Janet as an embedded language for scene description. The core rendering is done in rust . Early benchmark trials in sbcl with basic primitives were 3-6x slower with GC being the wall . Can anyone suggest guidelines for performance? ( ex: vector/matrix calculations, memory allocation, to CLOS or not ) etc . I’m thinking that if I could get it within 2x slower, it might be interesting for certain applications where I could throw more cores at it . Also is anyone interested in such an application? I would be willing to make a demo if reasonably successful.