The "highly configurable CL reader" is Eclector.

Canonical repo

s-expressionists/Eclector

Strandh mirror

robert-strandh/Eclector

Characterization

portable Common Lisp reader, error-recovering, optionally produces concrete syntax trees, customization via CLOS client pattern.

Three mechanisms carry the "highly configurable" claim:

1. Client pattern. The reader's behavior is selected by specializing CLOS methods on a client class. A consumer subclasses eclector.parse-result:parse-result-client and provides make-expression-result / make-skipped-input-result to shape what the reader emits. The reader is not a function with options; it is a protocol with implementations.
2. First-class error recovery. A recover restart is established whenever a recovery strategy is available for the signaled condition. Recovery is part of the reader contract, not an exception layer. The recovery messages themselves carry the diagnosis ("Treat the character as if it had been escaped", "Use NIL in place of the missing object"), which means downstream tools get a structured account of what was malformed and what assumption was made.
3. Concrete syntax tree output. The eclector.concrete-syntax-tree system returns source-tracked CST nodes rather than naked s-expressions. The reader becomes a spec-emitter for downstream static analysis.

GitHub :: robert-strandh

• SICL — fresh CL implementation, designed for portability and reuse rather than performance for its own sake
• Second Climacs — Emacs-like editor in CL, uses Eclector + Incrementalist for incremental parsing
• Cluffer — extracted buffer library, performance-oriented for large buffers
• CLOSOS — operating system inspired by CL's interactive environment
• Concrete Syntax Tree — library for source-tracked AST representation; counterpart to Eclector's CST output mode
• HIR — high-level intermediate representation as control-flow graph
• Cleavir — CL compilation framework (referenced across SICL and other implementations)

Strandh's program reads as: build the library that should exist, factor concerns aggressively, accept the cost of fewer shipped end-user applications. Eclector, Cluffer, Concrete Syntax Tree, and SICL form a deliberately-factored stack with cleanly separated layers.

Original ELS 2026 writeup row :: L2 / "Reader is a parser-as-protocol surface, not a constant."

Refined after Eclector inspection :: the claim survives and sharpens. The client pattern is the protocol surface; error recovery and CST output are additional protocol slots. The reader is best read as three protocols in one shell — token construction, error recovery, and parse-result shaping — each independently overridable.

Adjacent layer :: L3 (Specification). CST output mode means the reader emits the type of artifact downstream specification and analysis tooling consumes. Reader-as-protocol generalizes to reader-as-spec-emitter.

emacs-mcp-maximalist

Eclector's client pattern is a working example of the obarray-exposure thesis: behavior is a protocol clients subclass, not a hardcoded surface. The mapping is direct — every CL system that wants different reader behavior is already paying the cost of client subclassing; emcp asks the same of every Emacs subsystem.

elenctic-spec

Eclector's recover restart is externalized progressive hardening. Each recovery strategy is a refinement rule with a named justification. The pattern is what elenctic-spec would look like if it had a parser.

aq gossip protocol

parsing untrusted NDJSON with recovery rather than failing closed. Eclector's recovery model is what aq needs at the protocol-parser boundary.

guile-sage

the Scheme analog of Eclector — hygienic reader with client/recovery surface — does not exist in Guile to my knowledge. Worth a writeup as guile-sage adjacency.

• If Moringen's contribution is the headline and Strandh is co-author by courtesy, framing should center Moringen specifically. He is a major Eclector contributor in his own right; check the talk emphasis live.
• If "configurable" turns out to be narrower than the client protocol (e.g., readtable manipulation or reader macros at the standard CL level), the L2/L3 framing overreaches and should collapse to a plain L2 row.
• If the talk is mostly about a new configuration axis added to Eclector since the last public release, the corpus framing above is stale by one release cycle.

• ELS 2026 event page — parent writeup
• Scheme research — minimalist Lisp tradition for comparison; Eclector's hygiene/recovery model is the CL-side analog
• Elenctic Vibe Code Review — the methodology Eclector formalizes at the reader layer
• emcp-obarray-exposure-as-tool-contract.org (planned companion)
• eclector-recovery-as-elenctic-refinement.org (planned companion)