Scheme Request for Implementation 262,
"Extensible pattern matcher,"
by Daphne Preston-Kendal,
has gone into withdrawn status.

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

Here is Daphne's summary of the reasons for withdrawal:

This SRFI is withdrawn.

For the curious, the version with the changes that were to become the next draft is still at https://github.com/dpk/srfi-262. The current HEAD of the sample implementation, extensible-match, includes all changes up to this point. https://codeberg.org/dpk/extensible-match/commit/2a5834639666790bac14a89b05389eaea66c4d55

Here is the commit summary since the most recent draft:

• Add dark/light/system control to landing page.
• Fix typo.
• Withdraw.

Regards,

SRFI Editor

Scheme Request for Implementation 280,
"Monads",
by Hernán Ibarra Mejia,
is now available for discussion.

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

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

Here's the abstract:

Regards,

SRFI Editor

Alpha 3 of Aiki is out, an experimental programming language with a deliberately small semantic core.

Scheme is present in the heart of Aiki. Lists are fundamental, exact values are the default, expressions evaluate strictly left to right rather than by conventional precedence, and most capability grows through libraries instead of additions to the grammar or prelude.

Aiki goes in its own direction, but the influence is real. I care about compact language definitions, symbolic structure, exactness, and keeping the relationship between semantics and implementation visible.

One area I’ve been pushing recently is semantic profiling. Aiki can separate what a program asks the language to do from how the runtime realizes that work: exact numeric representations, calls, environment reuse, FFI boundaries, and other execution machinery. The point is to keep the semantics observable even as the implementation gets faster.

It is not intended as a Scheme replacement. It is a different language, but Scheme is one of the traditions (Go and Forth as well) that helped shape how I think about language design.

Alpha 3 announcement:

https://decuser.github.io/posts/aiki-alpha-3-release/

Repository:

https://github.com/decuser/aiki

Hi y’all. I’m currently working on a cursed case-lambda implementation with better inspectability for Chibi Scheme. As part of this effort, I need to extract the longest possible arglist from each case-lambda clause, so that the generated procedure with 2 unconditionally required arguments has a display like #<procedure 2+> instead of absolutely non-inspectable #<procedure 0+> that currently happens on Chibi.

So I’m kinda stuck. This is the macro I currently have:

(define-syntax case-lambda
  (syntax-rules ()
    ((case-lambda ((args ... . rest) body ...) ...)
     ;; We need to pass clauses twice
     ;; - First time to detect the shortest arglist
     ;; - Second time to process clauses
     ;; TODO: How do I make sure that all args ... have equal length???
     (%case-lambda ((args ...) ...) ((args ... . rest) body ...) ...))
    ((case-lambda (args body ...) ...)
     (%case-lambda (()) (args body ...) ...))))

The implementation of %case-lambda and other infra is of no importance, because, before I get to that, I must make sure that ((args ...) ...) is a list of arglists of the same length.

But how do I really do that? Any advanced macro wizards mind helping?

👋 Howdy! I needed to do some work on Markdown files recently (who doesn't). I noticed that existing libs which FFI to cmark only output HTML from Markdown directly, with no intermediate step. I want to have an AST available for easier manipulation.

This lib uses cmark-gfm to parse Markdown (and GitHub flavored Markdown) to an immutable Scheme AST. You can convert that AST to SXML in an HTML vocabulary, for the serializer of your choosing. It will also output directly to HTML, XML, CommonMark, and plain text if you like.

The docs are an example of parsing Markdown to SXML to build a small static site.

➡️ Available on Akku

✨ AI Disclosure: LLMs were used extensively.

Irregular post to invite everyone to post on their project(s), inspiration(s), dream(s)… and work opportunities…

Last edition: https://www.reddit.com/r/scheme/comments/vyv6x7/july_2022_what_are_you_up_to_schemers/

And yes, it's implemented in Chez Scheme

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

Interested part about moving to the multicore OCaml language model. As I know, Racket at 8.18 -> v9 choose the same way. Guile was posix threads compatible from 3.0? Chez biversion with or without real threads.

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

Nostradamus's verbal prophecy has finally come true: Version 6, compatible with R7RS, will be maybe was finally released in August 2026. Congratulations to the CHICKEN Team!!!

CHICKEN Scheme download page.

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