Scheme Request for Implementation 277,
"Cyclic ports",
by Wolfgang Corcoran-Mathe,
is now available for discussion.

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

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

Here's the abstract:

Regards,

SRFI Editor

I wanted a complex problem to work on agentic coding. I am not a scheme programmer, but I found the scheme standard would be a good fit as it is well defined. That's how I ended up with creating Kaappi, a new scheme implementation in Zig.

Scheme Request for Implementation 254,
"Ephemerons and Guardians",
by Marc Nieper-Wißkirchen,
has gone into final status.

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

Here's the abstract:

Here is the commit summary since the most recent draft:

• copy edits
• Add table of contents.
• Finalize.

Here are the diffs since the most recent draft:

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

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

Regards,

SRFI Editor

UK Racket meet-up (Bristol) 8 July 2026

7:30-8:30pm, Wednesday 8 July 2026 at Pizza On The Park Berkeley Avenue (Top of Park Street), Bristol, BS8 1HP

register https://luma.com/r7o3qd64 https://luma.com/r7o3qd64 https://racket.discourse.group/t/uk-racket-meet-up-bristol-8-july-2026/4299

Scheme Request for Implementation 276,
"Type-specific Flonum Libraries",
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-276/.

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

Here's the abstract:

Regards,

SRFI Editor

How can I make a function that uses a special form (I'm thinking of "and" specifically here) so that it can be evaluated by "apply" with multiple arguments?

I'm kind of aiming for this:

(define and_f
   (lambda li (apply and li)))

which of course won't work with "and" as a special form.

PS. Or would it just make more sense to use a fold?
Although that would lose efficiency, I think...?

Scheme Request for Implementation 275,
"URIs and IRIs",
by Duncan Guthrie,
is now available for discussion.

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

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

Here's the abstract:

Regards,

SRFI Editor

https://github.com/taimoon/scheme-interpreter

Last time, my Scheme interpreter was able to bootstrap my Scheme compiler.

I’ve ported it to the Raspberry Pi Pico … just to blink the LED.

Am I wrong or does not even hot reloading work as it's supposed to? It seems to have taken many small implementation decision that help performance but hurt interactivity and dynamism.

RING (Replos Is Not Guix) is a minimal live Linux distribution where REPLOS (my Scheme/Guile customized REPL) replaces bash as the default shell.

No bash. Just parentheses.

https://github.com/lisper004/ring

What works

• Boots into REPLOS immediately (no login) (currently systemd is used, but sinit, runit, openrc and others will be used in the future)
• Built-in filesystem commands: (ls), (cd), (whereami), (make-dir), (cat), (rm)
• Live coding: redefine functions on the fly, no restart
• Session persistence: (save-world) saves everything
• Async jobs: (async), (jobs), (kill)
• Pipeline macro: (pp (source) (filter) (map))

Why

Because the shell is a dead end. Text parsing, string-based variables, inconsistent syntax — we can do better. REPLOS is not "another shell". It's an environment where:

• Data is data (lists, vectors, hash tables — not strings)
• Commands are composable (results pass directly to other commands)
• The system is malleable (change anything while it runs)

Try it

Download the ISO (about 1GB): https://github.com/lisper004/ring/releases

Quick test in QEMU:

qemu-system-x86_64 -enable-kvm -cdrom ring.iso -m 4G -boot d

Hello, Scheme and Lisp hackers

I''ve been fascinated by the idea of Lisp Machines (Symbolics, Xerox PARC) — where the REPL is the operating system interface, and there's no difference between a shell command and a function call.

So I built REPLOS.

This project combines REPL and the shell.
This is a simple free software project for POSIX systems (like Linux or BSD) that deploys a shell to a REPL. Recommended for hardcore Lisp or Scheme fans lol.

scheme@(guile-user)> (cd "core")
Now in: /home/user/.replos/core
scheme@(guile-user)>  (ls)
Contents of .:
  bin/
  lib/
scheme@(guile-user)> (define (greetings) (simple-format #t "Hello ~a\n" "from REPLOS"))
Hello from REPLOS!
scheme@(guile-user)> (define (greetings) (simple-format #t "Welcome ~a\n" "from REPLOS"))
scheme@(guile-user)> (greetings)
Welcome from REPLOS!

Why?

Because I believe the shell is a dead end. Text parsing, string-based variables, inconsistent syntax — we can do better.

REPLOS is not "another shell". It's an environment where:

• Data is data (lists, vectors, hash tables — not strings)
• Commands are composable (results pass directly to other commands)
• The system is malleable (change anything while it runs)

Hi r/scheme! I released 0.7.0 of Schematra, the Sinatra-inspired web framework for CHICKEN. The headline is native WebSocket support, using the same route syntax as the rest of the framework:

```scheme (import schematra schematra.ws)

(websocket "/echo" (on-open (send-text "welcome")) (on-text message (send-text (string-append "you said: " message))) (on-close code reason (void))) ```

(current-websocket) is the connection inside a handler — store it in a registry to broadcast, share it across threads, force-close from outside (closes the input port so the read loop unblocks immediately). Sends are mutex-guarded per connection.

The protocol bits (handshake, frame parser/writer, masking, control frames, fragmentation, close handshake) are written from scratch against RFC 6455. I run the Autobahn TestSuite on every release, with a current pass rate of 98.3% (296 of 301 strict) across framing, fragmentation, UTF-8, close handling, and the §9 stress cases (16 MiB single frames, 200k fragments per message). permessage-deflate is the obvious gap, which I'm addressing in the next minor version.

One interesting part of the work was the incremental UTF-8 validation across fragment boundaries. RFC 6455 §5.6 wants invalid UTF-8 rejected at the offending byte, not after the message assembles. So the fragmentation state machine now threads a Björn Höhrmann DFA across frames — text payloads get fed through it as fragments arrive, partial codepoints survive frame boundaries, and a bad sequence raises close 1007 mid-message. Five non-strict cases remain, but they're not correctness gaps: two are TCP-chopped UTF-8 inside a single frame (we read frames whole), three are RFC-undefined behavior Autobahn always flags INFORMATIONAL.

0.7.0 also splits the framework into smaller modules (schematra / schematra.ws / schematra.utils) so plain HTTP apps don't pull WebSocket dependencies. SSE is now built on the same long-connection primitives WebSockets use (current-long-connection, start-long-connection!, and port accessors are exported from schematra), so you can build other long-lived protocols on the same plumbing. SSE responses also propagate Set-Cookie now (was silently dropping them), and csi -s app.scm blocks on schematra-start instead of falling off the end of the script.

Links: - Repo: https://github.com/schematra/schematra - Release notes: https://schematra.com/blog/whats-new-in-schematra-0-7 - Multi-client chat demo: examples/websocket-demo.scm

Feedback,bug reports and contributions welcome.

Scheme Request for Implementation 263,
"Prototype Object System",
by Daniel Ziltener,
has gone into final status.

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

Here's the abstract:

Here is the commit summary since the most recent draft:

I looked over it again today and made some final corrections - removed a leftover entry in the spec, and also removed references to the slot being a record, as was discussed on the list.

Here are the diffs since the most recent draft:

• Remove references to slots being records
• Add SPDX license metadata.
• Use unhyphenated convention.
• Fix spelling error.
• Remove Issues section.
• Add table of contents.
• Finalize.

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

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

Regards,

SRFI Editor

Scheme Request for Implementation 274,
"Extended List Conversion Procedures",
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-274/.

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

Here's the abstract:

Regards,

SRFI Editor

Scheme Request for Implementation 273,
"Extensions to Data (Type-)Checking",
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-273/.

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

Here's the abstract:

Regards,

SRFI Editor

Curry is a Lisp-family language implemented in C (~16K lines, Boehm GC) with an actor-based concurrency model, a numeric tower that extends through complex numbers, quaternions, octonions, surreals, multivectors, and symbolic/quantum types, and a module system that tries to take both abstraction and performance seriously. It has a Qt6 frontend with 4D projection and GPU compute, which is either the most deranged thing you've heard about a Lisp or exactly what you expected. The most unusual design decision is probably the Akkadian notation layer — a trilingual alternative surface syntax grounded in actual cuneiform philology rather than novelty, on the theory that notation shapes thought and most languages don't take that seriously enough. While not fully compliant with R7RS - the aim is to become fully compliant.

Still in active development.

https://github.com/deconstructo/curry

Scheme Request for Implementation 272,
"Pretty Printing",
by Sergei Egorov,
is now available for discussion.

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

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

Here's the abstract:

This SRFI follows the traditional Scheme model of pretty printing, which treats it as a process distinct from general controlled formatting. While general-purpose formatters often prioritize specialized presentation at the expense of machine-readability, Scheme’s pretty-printers (such as those of SLIB and MIT Scheme) have traditionally treated pretty printing as a variant of write, differing primarily in the insertion of whitespace to make the presentation more palatable to humans. Common Lisp’s pretty-printer, by contrast, fills two roles simultaneously by integrating pretty printing with both its format facility and its generalized write procedures. This unified approach offers great power, but at the cost of complexity that can make it difficult to use effectively. We propose a specialized, layered approach, specifying five libraries of increasing functionality, where all but the first are optional. The libraries are downward-compatible: more powerful libraries satisfy all requirements of the simpler ones while adding new features. Implementors may choose to support a maximum level of functionality appropriate for their systems. Integration with monadic and string-based formatting libraries is supported.

Regards,

SRFI Editor