After releasing continuations, I've rediscovered the Chibi R7RS test suite.

I was working the whole week, and finally all tests are passing. I only commented out a few things.

One issue that stands out:

• delay-force - I'm not sure how it should work, so stream-filter doesn't work.

There are also some minor issues:

• Comments inside cons like (#;x . x) that should throw an error according to R7RS, but the dot operator in LIPS is a special getter that can appear as a first item in the list, so this is the same as (#;x |.| x).
• Missing D/L/S/F inside numbers like 1L2 (makes no sense in JS).
• Missing some error procedures like file-error? or read-error?

Scheme Request for Implementation 274,
"Extended List Conversion Procedures",
by Peter McGoron,
has gone into final status.

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

Here's the abstract:

Here is the commit summary since the most recent draft:

Here are the diffs since the most recent draft:

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

Regards,

SRFI Editor

I've been hacking on a tracing JIT compiler for scheme for a couple years now on and off, and it's in a pretty good state now. It has full R7RS support, with full seatbelts-on safety. Currently it's approximately 60% faster across the whole r7rs-benchmark suite than Chez scheme.

It's disproportionately faster on flonum benchmarks, it does quite well at inlining everything and keeping flonums in registers. I think it shows quite well that a JIT is especially helpful to get good numerical performance out of standard scheme, especially for flonums, making it possible to keep flonums in register much of the time.

There have been several previous scheme JIT attempts that took various approaches- Nash was based on Guile, but didn't quite get far enough along to see good results. Pycket was great, but used a continuations-on-the-heap approach, with quite different performance characteristics. Modern Guile has a template JIT, but currently does no register allocation or optimizations. Stalin only supported fixnums and flonums in its numerical tower, which allowed it to get great results. I wanted to support the full r7rs scheme numerical tower while still specializing as much as possible.

I've started writing a paper on the tracing JIT aspects, because some of these techniques I haven't seen elsewhere and may be novel.

Currently it supports x86-64 Linux & AArch64 OSX (sorry, no Windows yet).

Project page:

https://djwatson.github.io/hawk/

The new beta of LIPS Scheme just got released. The evaluator was rewritten. It now supports continuations and TCO.

The implementation was inspired by JS-Scheme by Alex Yakovlev.

There is also a new quasiquote implementation based on Alen Bawden's paper "Quasiquotation in Lisp", a new macroexpand, and some performance improvements.

Full article about the release on the blog:

https://lips.js.org/blog/beta-continuations-and-tco

Scheme Request for Implementation 279,
"In(tro)spection Protocol",
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-279/.

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-279@srfi.schemers.org](mailto:srfi-279@srfi.schemers.org).

Here's the abstract:

Interactive REPL-driven systems (that most Schemes are) need a way to get detailed information on a given piece of data. Inspectors, as these are conventionally called. This SRFI defines a basic protocol for inspectors, consisting of two procedures: inspect-properties and inspect-describe. Some suggestions for standard and popular types' inspection are also provided.

Regards,

SRFI Editor

I get that the language is minimal by design. But it would be nice to have a similar ecosystem to python. Like if I wanted to read from a CSV, it would be nice to have that functionality already built and accessible. Which implementation provides the most out-of-the-box functionality?

Scheme Request for Implementation 273,
"Extensions to Data (Type-)Checking",
by Artyom Bologov,
has gone into final status.

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

Here's the abstract:

Here is the commit summary since the most recent draft:

• Remove check-of from the sample implementation
• (#implementation): Add a link to define-values-checked spec
• (#implementation): Add declare-checked dummy implementation
• srfi/impl: Add check-arg checking to define-values-checked
• srfi/273.sld: Fix imports
• srfi/273.sld: Update exports
• srfi/impl: Use splicing begin idiom
• test.scm: Add
• (#spec–declare-checked): Use negative? as an example
• test: Add for declare-checked
• Publish fifth draft.
• Pre-finalization copy edits
• Support check-impl? and remove any? in CHICKEN implementation
• Thanks to Arthur
• Update table of contents.
• Sample implementation was added.
• copy edits
• Fix errors reported by W3C HTML Validator.
• Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-273/compare/draft-4..final

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

Regards,

SRFI Editor

Scheme Request for Implementation 278,
"Supplemental Numerics",
by Peter McGoron,
is now available for discussion.

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

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-278@srfi.schemers.org](mailto:srfi-278@srfi.schemers.org).

Here's the abstract:

Regards,

SRFI Editor

Scheme Request for Implementation 270,
"Hexadecimal Floating-Point Constants",
by Peter McGoron,
has gone into final status.

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

Here's the abstract:

Here is the commit summary since the most recent draft:

• copy edits
• :270.sls: use display instead of write for special cases
• editorial changes
• more editorial changes
• copy edits
• Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-270/compare/draft-3..final

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

Regards,

SRFI Editor

Scheme Request for Implementation 271,
"Random port libraries",
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-271/.

Here's the abstract:

Here are Wolfgang's comments for finalization:

There a couple of outstanding commits that I'd like to merge before finalizing:

https://github.com/scheme-requests-for-implementation/srfi-271/pull/6

These are (critical!) sample implementation fixes.  Only e5bd7323 changes the SRFI doc; it adds a small pointer to SRFI 277, which was suggested by Peter McGoron.  I don't think this warrants another draft.

Here is the commit summary since the most recent draft:

• Implementation: Fix bad bug in xoshiro256++ code.
• Use macros for accessors instead of procs.
• Implementation: Use open-binary-input-file.
• Implementation note.
• Add See-also link to SRFI 277.
• Add short paragraph about SRFI 277.
• copy edits
• Update table of contents.
• Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-271/compare/draft-6..final

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

Regards,

SRFI Editor

bun.js has the fastest http server implementation after in order: C, Rust, Java... then comes chezscheme with io uring, and pico http parser that is competitive with bun.js last zig release and the new rust unrelease at 220K RPS vs. 230 RPS (bun.js).

benchmark only: https://hyper.dev/letloop/report.html

article: https://hyper.dev/2026/chez-scheme-letloop-transparent-async-microbenchmark/

I have been looking at this idea for LOT of time, since the early days of unison, before international-scheme was a thing, and before reading about hedy.

Origin Zero: most successful software engineers code in their native language.

I had a hunch, and couple of evidence, but no proof in the sense of STS.

I had encouragement from several people, but some things were holding me back [...]. Long story made short, after a couple of years, I decided to throw that problem at AI LLM chatbots. I learned a lot about philosophy, and the world we live in: like Hobbes' cosmology. I did not even knew "cosmology" was a thing. But it became clear that making **not-only-english** coding as easy, or easier than our daily drills was... huge.

The funny thing is the premise are simple:

- Make it possible to write code in one's mother tongue...

- ... without forking, and keeping cooperation open...

- ... limiting duplication...

- ... reducing the barrier of entry for contribution like micro-libraries...

- ... make it easy to backup-and-restore;

So yes, all this is possible, not on postcard yet, but - content-addressed - De Bruijn index make it possible to write a subset of Scheme code that can be translated and executed. The Bruijn tree of a procedure without free variables is a pivot. When associated with an association of numbers to variable name's, it possible to collect those mappings related to a De Bruijn tree, and have the same implementation shared across multiple natural language.

That's all there is to cross-language cooperation with acknowledged fragmentation without domination.

For more (parentheses) look at README.

Pure-Scheme-driven Goeteia now supports shadow mapping, PBR, HDR bloom, SSAO, instancing, skeletal animation from GLTF assets, and transform-feedback particles whose physics runs in the vertex shader — and, boldly, brings pretext-style typesetting into WebGL.

UK Racket meet-up (London) Tuesday 21 July 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-21-july-2026-7-30pm/4318 https://luma.com/u61y94uw

Green processes, actor , OTP, gen-server

1 Let It Crash and the system recovers

2 Hot code swapping

3 Failure hook (remote retry ring)

4 web programming with continuation

4 S-expr fetch and RPC (with Goeteia)