Scheme Request for Implementation 269,
"Portable Test Definitions",
by Andrew Tropin and Ramin Honary,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-269/.

Here's the abstract:

This SRFI defines a portable API for test definitions that is decoupled from test execution and reporting. It provides four definition forms: the universal is macro for assertions, testing for giving groups of assertions human-readable context, test for grouping assertions into independently executable units, and suite for organizing tests into hierarchies. The exported metadata auxiliary syntax attaches user-provided information to tests and suites to adjust the behavior of a test runner, for example to select tests by tags or to enforce timeout values. The API is tiny, yet capable and flexible. By focusing on the definition, and leaving execution semantics to test runners, this SRFI offers a common ground that can reduce fragmentation among testing libraries.

Unlike side-effect-driven testing frameworks (e.g. SRFI 64), this API produces first-class runtime entities, making it easy to filter, schedule, wrap them in exception guards and continuation barriers, run in arbitrary order, and re-run dynamically generated test subsets. In addition to the usual CLI test runners, it enables runtime-friendly test runners that integrate well with highly interactive development workflows inside REPLs and IDEs, significantly increasing control over test execution, and shortening the feedback loop.

To bridge the test definitions and test runners, the SRFI specifies a message-passing programming interface and test loading and execution semantics recommendations for test runner implementers.

Here is the commit summary since the most recent draft:

• Add SPDX copyright metadata to "TODO.md".
• copy edits
• Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-269/compare/draft-5..final

Many thanks to Andrew and Ramin and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

https://theourgia.dev

Open Source: https://github.com/guenchi/Theourgia

Theourgia is a knowledge base that agents and people write together.
The unit is a block, not a file: a design section, a function and a
decision record are each a block with a stable id, in one graph with
typed edges (implements, depends, supersedes, ...). Markdown and source
files are projections of the store, not the store.

I built it because my agents' memory kept failing in the same ways: files
that only grow, whole-file reads to find one rule, silent partial edits,
and several agents overwriting each other.

What 1.0 does today:

• A small query surface for agents: outline, search, refs, read, batch. Answers are one-line S-expressions, one mode, no pretty-printed alternative. On 56 questions over 20 real design documents, "search, then read the block that answers" cost 15% of the tokens of reading the whole document; "outline first" cost 20%.

• Many writers, no locks. Every agent and person writes under its own writer id, and a write goes into that writer's draft, which nobody else sees. Many writers can hold drafts on the same block at once. They meet at commit: a commit made against a baseline that has moved is refused with the reason (stale-baseline) and what changed, never applied over someone else's work. Every block carries its author's id for life.

• Isolated evaluation of unfinished work. eval --working runs code against one writer's own view (the committed store plus that writer's drafts) in a child process with no filesystem and no network. Ten agents can each run and test their own version of the same module without touching each other or the committed tree. Code round-trips through import/export as blocks; other languages execute via a runner table.

• One daemon per store, thin clients, an MCP server (reading a block is about 1 ms per tool call) and a VS Code extension: an outline tree, editing blocks as files, and "supply", which feeds signatures, call edges and diagnostics from the editor's language server into the graph.

It is written in R6RS Scheme on Chez Scheme, with libuv via igropyr. It
runs on macOS arm64 and Linux x86_64/aarch64. Install with Homebrew:

Known limits, also in the release notes: no FreeBSD or Intel Mac yet;
write latency grows with the store (about 0.13 s per insert at 100
events, 0.27 s at 3,000); a request longer than 30 s times out on the
client while the daemon finishes it; one store is one machine's.

Where it is going:

• query: Datalog-style rules over the in-memory state, for dependency chains, blast radius, unresolved rulings and the single live definition of a name.

• context: given a task block and a token budget, compile the working set (must-read premises, then evidence and background) and list what was left out and why.

• Function-level blocks for every language: a source file split at the symbol boundaries the language server reports, and assembled back into the same file on export. Today that granularity exists for Scheme; other languages are one block per file.

• The IDE side: a lens above each definition showing the design sections and lessons that refer to it, renames that list the prose that did not follow, and running only the tests that guard a changed block.

• Faster writes on large stores, FreeBSD and Intel Macs, an npm package, and a portable core that can compile to wasm.

Happy to answer questions.

Hi folks,

I would like to share something I have been building after struggling with other tools.

Just a bit of context, when working with LLMs I have been using Python Monty as sandbox for code mode, however I am not happy with it because:

1. I am a scheme fan boy 😂
   
2. Python is complex, a small language such as Scheme is a great use case for code generation in small models
   
3. It is a bit silly to call every single tool call sequentially

So I built Pingo, a lightweight scheme implementation without mutations(I know, heresy). It uses lambda zero, an opportunistic evaluation model (the Opportunistically Parallel Lambda Calculus, arXiv:2405.11361 — hence "lambda zero", λᴼ).

The trick is exactly the heresy: because nothing mutates, evaluation order doesn't matter, so the runtime is free to fire off independent external calls in parallel on its own. And
it's confluent, the parallel run gives the exact same result as running the program top to bottom. No async, no gather, no promises in the code the model writes. A call that's waiting on another call's result just parks itself and fires when that result lands.

So the model writes plain, sequential-looking Scheme:

(define coords (map geocode (list "Paris" "Tokyo" "Lima"))) ; 3 calls, fired together
(define temps (map forecast coords)) ; then 3 more, together
(apply max temps)

…and it runs in two parallel waves. The model never thinks about concurrency, it falls out of the data dependencies. That's the whole reason I gave up set!: mutation would force an
order and kill this for free.

Of course real tools aren't all commutative (some write to a DB, some send an email), so each tool declares an effect class, pure | independent | resource | ordered | irreversible.
Independent ones overlap; an irreversible one never gets dispatched speculatively. And since the language is pure end-to-end, every run is deterministic and replayable. I can record all the tool results and replay the whole program offline, exactly. Really nice for debugging agent runs.

On the Scheme side it's more complete than you'd expect for a toy: syntax-rules with hygiene, call/cc, dynamic-wind, define-record-type, exceptions (guard/raise), the usual list HOFs, and SRFI-115 regex.

Repo (Zig core + Python binding + a runnable example): github.com/igortoliveira/pingo

Would love this sub's take.

Scheme Request for Implementation 285,
"Dates and Times",
by Peter McGoron (steward, corresponding author), John Cowan (original design), Daphne Preston-Kendal (design and specification), and Arvydas Silanskas (implementation),
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-285/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [srfi-285@srfi.schemers.org](mailto:srfi-285@srfi.schemers.org).

Here's the abstract:

This SRFI details an API for storing and manipluating dates and times. This SRFI decomposes dates and times into dates (a count of days in the proleptic Gregorian calendar), clock times (time of day, independent of time zone), moments (instants in TAI), timezones (a possibly dynamic offset from UTC), timestamps (a date, clock time,and timezone), and time deltas (measurement of elapsed time). By doing this, a Scheme program can operate on days in different calendars and timestamps in different timezones.

Regards,

SRFI Editor

Scheme Request for Implementation 284,
"define-typed",
by Arne Babenhauserheide,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-284/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [srfi-284@srfi.schemers.org](mailto:srfi-284@srfi.schemers.org).

Here's the abstract:

This SRFI defines the forms define-typed and define-typed* for creating procedures with checked type boundaries. It allows checking the arguments and/or the return value or values with simple predicate procedures and raises exceptions on usage when they don't match. The form define-typed* supports keyword and optional arguments. The implementation for Guile is optimized to allow the compiler to use the predicates as guarantees to create more optimized code and provides type information for runtime introspection that supports SRFI 283.

Regards,

SRFI Editor

(sixteenth RacketCon) tickets on sale now

October 3-4, Oakland, Ca https://con.racket-lang.org/

Get your tickets now at https://www.eventbrite.com/e/racketcon-2026-tickets-1997181002140

* Professional $120
* Patron $150
* Student/Retired $35

Includes Saturday lunch and Saturday evening social event.

**Can’t attend in-person?**

* Remote Participant $10
The live stream is publicly available, but buying this ticket helps pay for the live stream and ensure its availability for the entire community.

Scheme Request for Implementation 283,
"(Type-)Check Introspection",
by Artyom Bologov,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-283/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [srfi-283@srfi.schemers.org](mailto:srfi-283@srfi.schemers.org).

Here's the abstract:

This SRFI focuses on the introspection and type inference sides of typing / checking. It provides several useful procedures deriving types / checks for arbitrary data. procedure-check-of and check-of work with checks, as in SRFI 253. procedure-type-of and type-of work with implementation-specific types. check->sexp provides a way to serialize opaque checks from above into more readable s-expressions.

Regards,

SRFI Editor

Scheme Request for Implementation 282,
"Missing R7RS (Type) Predicates",
by Artyom Bologov,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-282/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [srfi-282@srfi.schemers.org](mailto:srfi-282@srfi.schemers.org).

Here's the abstract:

Types and entities deserve predicates so that their user can meaningfully understand what they are dealing with, and usefully dispatch on them in their code. However, some R7RS “types” have no respective predicates. This SRFI defines them.

Regards,

SRFI Editor

and is this the convention in all members of the lisp family?

Scheme Request for Implementation 277,
"Cyclic ports",
by Wolfgang Corcoran-Mathe,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-277/.

Here's the abstract:

Here is the commit summary since the most recent draft:

• Consistently refer to SRFIs through bibliography.
• Update table of contents.

Here are the diffs since the most recent draft:

Many thanks to Wolfgang and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

I'm making a scheme implementation that's like lua, a vm register and bytecode-based with line level debug info

To embed dummyscheme to a host program, just copy source files under src, and write some plugin methods to register them to dummyscheme'vm easily as lua

Working in progress, not fully tested

Bay Area Racket Meetup - TODAY September 5th, 3pm at Noisebridge, SF.

https://luma.com/6y4sbfln

https://racket.discourse.group/t/bay-area-racket-meetup-september-5th-3pm/4359

#lisp #scheme #Racket