Planet Scheme

Thursday, May 28, 2026

The Racket Blog

Racket v9.2

posted by Stephen De Gabrielle and John Clements


We are pleased to announce Racket v9.2 is now available from https://download.racket-lang.org/.

As of this release:

  • The match form checks that when non-linear patterns (patterns where the same variable is used multiple times) are used with ..., the two parts of the matched value actually are equal. Additionally, match rejects non-linear patterns where one use of the variable is used with ... and another is not. This repair could cause existing code to fail.
  • Typed Racket’s types for the asin and acos procedures correctly handle situations where the function produces a complex number, avoiding unsound results that were previously possible. This repair could cause existing code to fail at compile time.
  • The #%foreign-inline core syntactic form provides unsafe access to facilities provided at the linklet layer by a Racket implementation. This means that any code that handles all core forms by enumeration will need to be updated.
  • Unicode 17.0 is used for character and string operations.
  • This release includes internal support for a more static “ffi2” foreign interface (to be used in a future package).
  • The terminal-file-position function counts bytes written to ports connected to a terminal, such as stdin and stderr.
  • Cross-phase persistent modules allow more types of quoted data.
  • The implementations of member, memw, when, unless, let/ec, and cond are rewritten to use only racket/kernel syntax
  • The impersonator-property-predicate-procedure? function identifies procedures created by make-impersonator-property.
  • In Typed Racket, polymorphic struct types are printed using type arguments (e.g., (Array Byte)) rather than exposing an internal representation.
  • The stepper’s display of numbers better matches the language settings.
  • Scribble documents that do not use the Racket-manual style get an initial-scale of 1.0, instead of the manual style’s 0.8, but this can be configured using the initial-scale property.
  • By default, margin notes appear inline for narrow displays in all styles, not just in the Racket-manual style.
  • Big-bang programs distributed as .dmg files correctly handle the close-on-stop feature.
  • There are many other repairs and documentation improvements!

Thank you

The following people contributed to this release:

Alexander Shopov, Alexis King, Asilo, Bert De Ketelaere, Bob Burger, Bogdan Popa, Chung-chieh Shan, François-René Rideau, Gustavo Massaccesi, Ilya Klyuchnikov, Jade Sailor, Jamie Taylor, John Clements, Jonathan Simpson, LS_Hower, Matthew Flatt, Matthias Felleisen, Mike Sperber, Pavel Panchekha, Philippe Meunier, RMOlive, Robby Findler, Roman Klochkov, Sam Tobin-Hochstadt, Shu-Hung You, Stephen de Gabrielle, Tejas Sanap, Vincent Lee, and Wing Hei Chan.

Racket is a community developed open source project and we welcome new contributors. See racket/README.md to learn how you can be a part of this amazing project.

Feedback Welcome

Questions and discussion welcome at the Racket community on Discourse or Discord.

Please share

If you can - please help get the word out to users and platform specific repo packagers

Racket - the Language-Oriented Programming Language - version 9.2 is now available from https://download.racket-lang.org

See https://blog.racket-lang.org/2026/05/racket-v9-2.html for the release announcement and highlights.

Thursday, May 28, 2026

Friday, May 22, 2026

Scheme Requests for Implementation

SRFI 263: Prototype Object System

SRFI 263 is now in final status.

This SRFI proposes a "Self"-inspired prototype object system. Such an object system works by having prototype objects that are derived repeatedly to modify, extend, and use them, and is interacted with by passing messages.

by Daniel Ziltener at Friday, May 22, 2026

Thursday, May 21, 2026

Scheme Requests for Implementation

SRFI 274: Extended List Conversion Procedures

SRFI 274 is now in draft status.

A set of modest extensions to list conversion and list copying procedures is proposed that aligns them with other conversion and copying procedures and allows for some operations on improper and circular lists. Authors of further SRFIs that include list conversion procedures are encouraged to align their behavior with the behavior in this SRFI.

by Peter McGoron at Thursday, May 21, 2026

Wednesday, May 20, 2026

Updates from the R7RS standards process

Procedural Fascicle, Draft #1

Working Group 2 is pleased to announce the first draft of the second part of the R7RS-Large Foundations, the Procedural Fascicle". This draft encompasses the familiar block programming forms, such as lambda, let, if, or, and set!.

The draft is available here: https://r7rs.org/large/fascicles/proc/

The biggest new feature is the ability to mix definitions and expressions in bodies, such as the body of a lambda. For example, the following is now valid:

(define (map f lst)
  (unless (list? lst)
    (error 'map "not a list" lst))
  (define (map* lst acc)
    (if (null? lst)
        (reverse acc)
        (map* (cdr lst) (cons (f (car lst)) acc))))
  (map* lst '()))

We welcome any and all comments on the draft. Anyone can comment by

by code@mcgoron.com (Peter McGoron) at Wednesday, May 20, 2026

Monday, May 18, 2026

Scheme Requests for Implementation

SRFI 273: Extensions to Data (Type-)Checking

SRFI 273 is now in draft status.

The original SRFI 253 established a basis for type-checked (or otherwise checked) data handling. But it lacked some quality-of-life features. This SRFI extends SRFI 253 to match existing implementation practice and common sense. Provided extensions are: check aliasing with define-check; pre- and post-declaration of type / check with declare-checked; return value checks in lambda-checked, case-lambda-checked, and define-checked; the derive-check form to derive a suitable check for an expression; type-matching syntax check? and check-impl? in syntax-rules, and some checking utilities.

by Artyom Bologov at Monday, May 18, 2026

Wednesday, May 13, 2026

Scheme Requests for Implementation

SRFI 272: Pretty Printing

SRFI 272 is now in draft status.

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.

by Sergei Egorov at Wednesday, May 13, 2026

spritely.institute

Hoot 0.9.0 released!

We are excited to announce the release of Hoot 0.9.0! Hoot is a Scheme to WebAssembly compiler backend for Guile, as well as a general purpose WebAssembly toolchain. In other words, Scheme in the browser!

This release contains new features and bug fixes and since the 0.8.0 release back in February.

Use Hoot in the upcoming Lisp Game Jam!

On Friday (May 15th 2026), the Spring edition of the Lisp Game Jam will begin! It's a 10-day long game jam where participants make games using their favorite flavor of Lisp.

Does making a small web game in Scheme using Hoot sound appealing to you? Well, then we have just the thing to get you started: the Hoot game jam template! This template project has everything you need to start making an HTML5 game with Hoot quickly.

The template repository includes:

  • Bindings to the necessary web APIs to make an interactive game with HTML5 canvas

  • A Makefile for compiling, running a development web server, and generating a .zip bundle for uploading to itch.io

  • A very simple Breakout-like example game that demonstrates how to put all the pieces together

Thanks to contributor Gonzalo Delgado, the game jam template now features gamepad input support!

For more inspiration, here are some games made with Hoot for past jams:

Now, onto the release notes!

Toolchain changes

  • Added the concept of host provided types. Useful for Hoot on Wastrel support.

  • Switched from legacy exceptions to standard Wasm exceptions, which were officially adopted in July 2025 but have been available in browsers for much longer. The --experimetal-wasm-exnref flag is passed to NodeJS in case it is old enough to still require this feature flag (which is currently the case for Guix).

  • Added support for DWARF custom section.

Compiler changes

  • Replaced function name/source metadata with DWARF.

  • Changed default debug level to 1, which now includes emitting DWARF. For a production build stripped of all debug data, use debug level 0 (-g0 in the CLI) or strip the binary afterwards using hoot strip.

  • Update compiler backend for new primitive bytevector predicates introduced in Guile 3.0.11.

  • Added support for bitvector literals on big endian host systems.

Runtime changes

  • Floating point number to string conversion is now implemented in Scheme rather than relying on an import. This makes binaries slightly bigger but makes it easier to support Hoot on Wastrel and non-JavaScript runtimes generally.

  • Bignum imports have been monomorphized to ease non-JavaScript runtimes (Wastrel, again).

  • Scheme binaries now export a main function that takes 0 arguments and returns 0 values that invokes the internal $load function. This makes it posible for Wastrel to boot a Hoot program without support for the Scheme reflection interface.

  • Added DWARF parser to reflect.js.

  • Removed fsqrt import in favor of using f64.sqrt instruction.

Scheme changes

  • Range errors now include the range in the exception irritants list.

  • Added uint8array->bytevector procedure to (hoot typed-arrays).

  • Vectors are now considered self-evaluating in (hoot expander).

  • Added internal (hoot module-syntax) module to gather runtime module macros and support code.

  • define-record-type now works in the Scheme interpreter for record types with up to 8 fields. (Supporting more than 8 fields is planned but will require larger changes to the Hoot runtime.)

CLI changes

  • guild compile-wasm has been deprecated in favor of the new hoot compile subcommand. Both commands accept the same flags.

  • Added hoot help subcommand.

  • Added hoot strip subcommand to remove debugging information from a Wasm binary.

  • Feature flags have been split out from debug options in hoot compile/guild compile-wasm. For example, -gruntime-modules is no longer valid; use -fruntime-modules instead. The -g flag now exclusively handles debugging data such as whether to emit DWARF or a names section. The -f flag handles things that change program behavior such as whether to include a runtime module system for use with the Scheme interpreter.

Documentation changes

  • Updated manual to use hoot compile instead of guild compile-wasm.

  • hoot compile --bundle is now recommended in web deployment section rather than manually copying support files.

Bug fixes

  • The repl.js file missing from 0.8.0 (which broke hoot repl) is now included in the release tarball. Apologies for the oversight!

  • Fixed pathologically large function emitted by lower-globals, which Wasm engines such as Wastrel can struggle with. Instead, many smaller functions are emitted.

  • hash-set!, hashq-set!, etc. now return the passed value. This matches Guile's behavior and allows more existing Guile programs to work as expected.

  • Fixed bug in parsing zero-length custom sections in Wasm binaries.

  • Fixed validation of return_call_indirect instruction.

  • Fixed missing EOF handler in REPL meta-command reader.

Browser compatibility

  • Compatible with Safari 26 or later.

  • Compatible with Firefox 121 or later.

  • Compatible with Chrome 119 or later.

Get Hoot

Hoot is available in GNU Guix:

$ guix pull
$ guix install guile guile-hoot

Also, Hoot is now available in Debian, though it will take awhile for this release to make it there.

Otherwise, Hoot can be built from source via our release tarball. See the Hoot homepage for a download link and GPG signature.

Documentation for Hoot 0.9.0, including build instructions, can be found here.

Get in touch

For bug reports, pull requests, or just to follow along with development, check out the Hoot project on Codeberg.

If you build something cool with Hoot, let us know on our community forum!

Thanks to our supporters

Your support makes our work possible! If you like what we do, please consider becoming a Spritely supporter today!

Diamond tier

  • Aeva Palecek
  • David Anderson
  • Holmes Wilson
  • Jonathan Frederickson
  • Lassi Kiuru

Gold tier

  • Alex Sassmannshausen
  • Juan Lizarraga Cubillos

Silver tier

  • Austin Robinson
  • Brit Butler
  • Charlie McMackin
  • Dan Connolly
  • Deb Nicholson
  • Eric Bavier
  • Eric Schultz
  • Evangelo Stavro Prodromou
  • Evgeni Ku
  • Glenn Thompson
  • James Luke
  • Jonathan Wright
  • Michel Lind
  • Mike Ledoux
  • Nathan TeBlunthuis
  • Nia Bickford
  • Noah Beasley
  • Steve Sprang
  • Travis Smith
  • Travis Vachon

Bronze tier

  • Alan Zimmerman
  • Aria Stewart
  • BJ Bolender
  • Ben Hamill
  • Benjamin Grimm-Lebsanft
  • Brooke Vibber
  • Brooklyn Zelenka
  • Carl A
  • Crazypedia No
  • Ellie High
  • François Joulaud
  • Gerome Bochmann
  • Grant Gould
  • Gregory Buhtz
  • Ivan Sagalaev
  • James Smith
  • Jason Wodicka
  • Jeff Forcier
  • Marty McGuire
  • Mason DeVries
  • Michael Orbinpost
  • Neil Brudnak
  • Nelson Pavlosky
  • Philipp Nassua
  • Robin Heggelund Hansen
  • Ron Welch
  • Stefan Magdalinski
  • Stephen Herrick
  • Steven De Herdt
  • Tamara Schmitz
  • Thomas Talbot
  • William Murphy
  • a b
  • chee rabbits
  • r g
  • terra tauri

Until next time, happy hooting! 🦉

by Dave Thompson at Wednesday, May 13, 2026

Saturday, May 9, 2026

Idiomdrottning

Pixel art apps on F-Droid, comparison

Here’s a comparison between the three pixel/​sprite/​tile making apps I could find on F-Droid. I know there’s stuff in that vein on Varvara, but I haven’t figured out a good way to run Varvara apps on Android yet, especially in a way where I could get files in and out. (Definitively still interested in that approach though.) So here’s PxerStudio, Pixel Artist, and PixaPencil.

PxerStudio

First I tried PxerStudio. My initial review of this was: Okay, I can use this one, but I really hope one of the other options is better. Why?

Because it’s “floaty” and “fidgety” in a way that makes my nerves knot up. This floatingness starts right away even when selecting the resolution (for all three of these apps I used 16×16) requires those aaaaawful number-sliders Android has. It feels horrible trying to get it to land on exactly sixteen.

Same goes for selecting colors: there’s no way to use palettes or entering hex digits or RGB values. There’s a color picker which you’ll have to rely on religiously. So if you reverse-engineer the project format you could open images with a palette base layer to pick from.

Also don’t press “back” by mistake because it might close the whole thing down (without saving, it seemed like,o but I’m not sure).

Placing the actal pixels is the biggest problem. There are three options: a drawing tool (basically a one pixel brush), a line tool, and a box tool. And a flood fill that does work well. The line tool doesn’t actually draw full lines if you go at an angle; it’s really conservative and only places the pixels it’s sure of. So it might only place two or three pixels inbetween long gaps that you’d have to fill in by hand. That’s fine. The biggest lack is a way to just tap in pixels. Tapping on a pixel doesn’t do anything, only dragging does. So I’m constantly adding pixels by mistake when I accidentally drag but where I do want to add pixels, I have to drag. The box-drawing tool is almost the best tool since you can make 1×1 “boxes” to make pixels but that still requires dragging.

There’s full undo support though, and that mitigates a lot of these issues. But wow is this app an anxiety factory for me.

The export options are great (of the three apps this one exports the best) and unique among the three apps is that you can use layers. The layers is a killer feature that might push me into choosing this one over the others.

Pixel Artist

Okay TL;DR: probably don’t use this Pixel Artist until they implement better export options.

Here we go the opposite direction with an extremely minimalist app that only has one drawing tool: tap on a square (a pixel) to make it the selected color. Long press on a pixel to color-pick from it. No other tools, this is all you’ve got, and the only available size is 16×16 which might be a showstopper for some projects but suits me perfectly.

In addition to the awesome color-pick-by-long-press super power, there’s a predefined palette along one edge (and that’s your only “toolbar”, the palette); you can’t import palettes but you can replace colors by long-pressing them. However, those new colors you can only select by R, G, and B sliders (and no number so you can’t select a specific R, G or B value, just ballpark). If you save or reload a file, you still get the default palettes and your customly added colors are gone. You can still color pick them from the image but you can’t copy picked colors into the palette. So maybe don’t use custom colors except the default palette is bad with no ramps, all colors the same brightness, a single yellow and seven nearly indistinguishable greens.

There’s no zoom option either, so on the Retroid Pocket Classic, the image doesn’t fit without panning (although I can see the whole image by opening the file menu, where it’s embedded) and on the Paper 7 (which has fewer pixels than the RPC so apparently this is determined by display size, not pixel density), there is a huge white margin to the right and below the image.

I can’t comfortably draw with a “tap by tap” app like this (and I hope you like tapping because a 16×16 image requires 256 taps), but if I sketch on 1mm grid paper, I can then “digitalize” those paper sketches by usig this Pixel Artist app as a “data entry tool”. The garish, unramped colors would’ve been fine if if they had at least been distinguishable, since I can re-palette them in the game engine and I’d only be using the app to get a digital representation of a paper sketches and I can use all kinds of colored pens when making the paper sketch versions on grid paper.

Dragging with a single finger pans the image and tapping sets a pixel to the chosen color. There’s no undo at all.

So far some pros and cons: great for quickly placing pixels with precision, but that’s all it can do. Now for what breaks it: exporting the images! Three issues with that:

  1. You need to remember to turn off the grid before exporting, otherwise the grid will be visible in the image (and it’ll have a different resolution so it can fit the grid). Not a dealbreaker but I do want the grid on while drawing (that especially goes for this app with it’s dot-by-dot mental model) so having to turn that off before exporting each image is a chore.

  2. One pixel is not one pixel. It’s display dependent. So images I made on the RPC are 1280×1280 (that’s 80×80 pixels per pixel) while images I made on the Paper 7 are 640 by 640 (so 40 by 40 pixels per pixel). That’s nothing imagemagick can’t fix (it’s only a waste of space and bandwith but I can live with that).

  3. Now to the biggest problem: that big exported picture is a JPEG for some reason! What in the heck! Yeah, yeah, ImageMagick’s convert utility can probably reindex and requantize the images to hopefully dodge any artifacts so the JPEG decision doesn’t have to ruin anything except it also wastes space.

So okay, my lede on Pixel Studio said not to use until they fix exports not literally true because ImageMagick can rescue the image data. Just not easily.

PixaPencil

Uh-oh! F-Droid warns that “source code no longer available” for PixaPencil, so I was really hoping it wasn’t gonna be the best of the three. (Turns out the sitaution is that the app has gone proprietary. It’s “source-available” but for our DFSG purposes it might as well be in /dev/null. Except! Older versions can be forked! That’s a distinction I sometimes wish F-Droid would make but maybe that’s splitting hairs. I see that on F-Droid apps and I think oh no there’s been a drive failure and the source code is literally gone (I’ve been there, fam♥︎😭) but what happened instead is that the main dev is making no more DFSG-free updates so may the forks be with you. Lookin at the sourcecode there’s a subpackage named “dao” which is a pretty bad red flag for me.)

Unfortunately it might the best one.

How good is it at the basics?

It doesn’t have layers, is the major missing feature that PxerStudio had. Export options are also limited compared to PxerStudio but it’s a good clean PNG where you can select raw (one pixel is one pixel, great for using in the game project) or scaled (one pixels is bigger, great for display and posting). That’s all I need. Other tools can take it from there. The PNG images are in indexed, 8-bit PaletteAlpha format which is perfect for this.

Of the three apps, this is the only one that lets you actually enter any hex triplet color (or I guess hex quadruplet since there’s alpha too). You can even import entire palettes (You need to use a specific website to do that, though. It’s called “Lospec”. You need to paste only the last part of the URL, the “palette identifier”.).

The only way to zoom is the zoom buttons and the only way to pan is the panning tool. Okay, I love that restriction. This means that dragging my finger (or pen but my pen is broken right now) over the screen does only one thing: the selected tool. Tapping pixels to add them is even more reliable than in Pixel Artist (where it semeed like it sometimes did require a little effort), and as I said, Pxer Studio can’t even do that.

The line tool is crisp and reliable and there are a couple of other tools like boxes, flood fill, polylines and so on.

Beyond the basics

I’ve got to remember than if anything in this section is bad, that’s fine, just don’t use it, it’s a “bonus section” anyway. (For example, the project I’m working on doesn’t benefit from dithering.) There’s mirror symmetry, dither and spray tools, other brush shapes (and your currently selected brush is used when using the line tools). There’s darkening, lightening, and color-inverting the entire image (maybe would’ve been more useful if there had been layers and/or selections).

There’s also a “darken/lighten” tool which I love and hate. Be careful when using it because if you accidentally lift your pen, it re-darkens already darkened squares or re-lightens already lightened ones, and it also lightens any black outlines you have. (Again, no layers…)

It does not stick to the ramps in your palette, is the major problem. Those caveats aside, I’m still thinking I might want to use this tool a lot, to crank out a bunch of sprites quickly: I’ll just make a way simpler hue-only palette for the main flats and then shade them with this darken tool, being more restrictive against lighten since that can mess up the outlines. I can re-palette the sprites in the game engine anyway later. But, this darken/lighten tool is at the expense of a more generic “only replace selected color” draw setting that MS Paintbrush had back in the early 90s. It’s both worse and better because if you’re satisfied with what it does, it’s fewer clicks to add a li’l depth to your images and make them a li’l less NES and a li’l more TG-16.

I also like the “pixel perfect” setting. With it on, I can draw sloppily and it deletes stray pixels after I lift my finger. I love that it’s not the default because it’s pretty surprising behavior, but it’s a great option that I’ll use often if I do go with this app.

Emacs in an SSH

My original plan when I got this 1mm grid paper was to enter the pixels directly into Emacs and writing a li’l something something to convert it into pixel data (and then I learned that pceas has a hex-nybble-to-pixel-index importer built in which made this even easier).

I mean something like:

00A0
00A0
00A0
00A0

(that’s a li’l 4 by 4 toy example, the real entries would be 8 by 8 or 16 by 16.)

I quickly learned that as much as I actually do type stuff in here with the OSK, that might be fine for coding but not so much for this amount of “data entry”.

In other words, I can’t do it on-the-go unless I bring my keyboard. But at home or when I do have my keyboard this might still be the best method for getting paper-sketched ideas into the game! I can choose homerow glyphs or otherwise comfortably-placed glyphs while entering and fix them with a tr filter.

Kind of sucks that the grid paper has “major grid line” every ten lines instead of every eight lines but I can live with that (I’ve already made plenty of sprites with this method and it works fine).

Nostalgia for my desktop

When I still had my desktop computer I loved making pixel art in a combination of Inkscape, MyPaint and GIMP #ChangeTheName. Waaay back in the day I’ve used Synfig also. Inkscape might sound like a bad choice for pixelart and it was, until I found some extensions that made it better. The icons I made for Heartfeed where all made in Inkscape, manually rehinted for every size. (Well, some of them started life in Blender but I did the hinting in Inkscape). Knowing that outlined objects need to start at .5-offset pixel increments while un-outlined objects need to start at integer pixel increments, that sort of stuff is necessary to be aware of when working with Inkscape. It’s definitively not safe-and-good straight out of the box. It’s just that at the time my brain was just really attuned into Inkscape. GIMP #ChangeTheName is also great for color curves, scaling options, applying gradients and so on, and there’s a million formats to export and import, and it’s great for making animations easily.

CSP (non-FOSS alert)

Then after I moved apartments and couldn’t use my desktop anymore because of lack of physical space and lack of power outlets and I’m relegated to tablets I got CSP for the iPad but I’ve let that subscription lapse. Looking into maybe getting a cross-device renewal later that works on both iPad and Android.

CSP was okay for pixel art actually. I wasn’t that happy with how the one image I made with it turned out, but I was pretty happy with the tools. The “pixel perfect” drawing mode that PixaPencil has would’ve been welcome, but in exchange it’s freeing to be able to use pencil sketching and painting tools for the first iterations and then go down to the nitty gritty for refining them. We get all symmetry lines, skewing, molding, pushing, warping, masking, layer joy we could ever need and can then cook it down to pixel size.

That’s an approach that none of these specialized pixel art apps can do.

It’s the difference between drawing and painting. Sometimes painting feels like molding clay, I love it, I can push and pull, add and sculpt. Sketching has some of the same quality with a loose-enough pencil scribbling approach (I like normal HB pencils the best). Drawing implies laying down the lines exactly where they should be and getting them right in the first try. That’s the mentality the pixel apps require and that’s a pretty huge limitation on all of them. They’re very waterfall and not so iterative.

Conclusion

Nothing I can do on tablet, among the options I’ve found so far, comes close to what I could do on my Debian desktop with MyPaint, Krita, Blender, Inkscape, and GIMP #ChangeTheName. Except for CSP which did come pretty close.

Of the three Android options I’m gonna go with the old version of PixaPencil in the hope of forks. I’m not saying no to the Varvara stuff if I can get them to work on Android although I’m working on a project that uses four-bit color, not two-bit.

If I ever rejoin society I might go trawling on the App Store and Play Store (including considering maybe renewing my CSP subscription).

Definitively not throwing out my 1mm grid paper either. After looking at these pixel apps I’m so glad I got it. I’m sure some of the sprites and tiles will be drawn entirely that way and hand-entered into Emacs, others will be drawn mostly that way, and hand-entered and refined in one of the pixel apps, some will made primarily in the pixel apps based on loose paper sketches, and some won’t use the grid paper at all and that’s fine too. I’m completely overwhelmed by the amount of art I have to make so I really appreciate the multi-faceted approach.

by Idiomdrottning at Saturday, May 9, 2026

Sunday, May 3, 2026

Scheme Requests for Implementation

SRFI 271: Random port libraries

SRFI 271 is now in draft status.

This SRFI proposes a pattern of libraries for binary input ports that produce random bytes. Libraries are divided into “randomized” and “determinized” categories to address different uses of random data. The design leaves the details of random number generation to the implementer and the transformation of bytes to other types (floats, etc.) to higher-level libraries. A mechanism for saving random-port states as bytevectors and for propagating those states to new ports is also provided.

by Wolfgang Corcoran-Mathe at Sunday, May 3, 2026

Friday, May 1, 2026

Scheme Requests for Implementation

SRFI 270: Hexadecimal Floating-Point Constants

SRFI 270 is now in draft status.

Floating-point numbers are usually stored in radix 2, but are written by users in radix 10. This SRFI introduces Scheme syntax for hexadecimal floating point constants based on C99's syntax, that use radix 16 for writing the integer and fractional part, and a radix 10 exponent part that raises the whole value to a power of 2.

by Peter McGoron at Friday, May 1, 2026

Wednesday, April 29, 2026

jointhefreeworld

Why I Still Reach for Scheme and Lisp Instead of Haskell

There is a persistent tension in software engineering between the beautiful, mathematically pure ideal of a program, and the messy, pragmatic reality of just getting things done. Over my career, I’ve explored the depths of both extremes in an attempt to find my personal sweet spot for hacking.

Before you sharpen your keyboards and start a flame war over the title, let me point out that I haven’t written this post to talk bad about Haskell, or any other tool for that matter. In fact, I love Haskell. I taught myself, banged my head against the wall over the course of three years, and built several real-world projects with it (some even became a bit lucrative).

Between my time in the web development world, the Go world, the JVM world with Java, Scala and Kotlin, and my long history hacking in Lisp ( Emacs, Common, Scheme), I have come to deeply appreciate functional programming.


Enlightening as it can be  #

Haskell has what likely is the most amazing, enlightening and complex type system to work with (as do more ML languages).

It is also the undisputed king of introducing mathematical ideas and concepts to programming, and popularizing them. Haskell circles are frequented by PhDs, computer science researchers, category theorists and all kinds of smart people (don’t underestimate other communities, like Schemers though).

Some of the amazing innovations of Haskell or that it has helped popularize, which blew my mind several times:

All these kind of things often feel bolted-on or missing entirely in other languages!

For all its brilliance, Haskell resists most of the attempts people make to just hack and write useful code quickly.

Specially people new to functional programming (or god forbid new to monads and functors! A monad is just a monoid in the category of endofunctors, what’s the problem?)


When pragmatism enables actual productivity  #

Scheme (and Lisp in general) might lack Haskell’s innovations and purity, favoring a minimalistic flexibility instead, but it mixes practicality with functional beauty in a way that makes it a functional language for human beings.

Actually, in my opinion, Scheme (and Lisp) allows you to express complex systems and problem domains in more simple terms than any other language can.

Take a recent adventure of mine, for example. I was spinning up a prototype for a bookmark management tool, just one of many projects I’ve come up with over the years.

I started in Haskell as I thought the beauty of data modelling and pure side-effect-free reasoning would work well: it’s also fast, elegant, and once you’ve used modules like Parsec, Servant, and optparse-applicative, it’s tough to imagine writing certain things, like a parser, without it.

One of the steps in the proof-of-concept was transforming some data models to XML and output them to a file.

If I were doing this in Kotlin or Java, it would be trivial: drop a dependency into Gradle, wire up Jackson or a standard DOM parser, and ten minutes later the data is in memory and ready to manipulate.

After a frustrating hour with my Haskell project, and even after years of experience with the language, I was still wrestling with the dependencies, and later with monadic API, and I ended up giving up on the whole thing after I noticed I even forgot what I was doing in the first place.

This has often been my friction point with Haskell. It is beautiful, but it fights you when you just want to get your hands dirty and prototype, without a big design upfront even though type-driven development can also be nice and work well in some cases.

Scheme ( GNU Guile for me) doesn’t have Haskell’s brutally efficient compiler, although it is quite speedy thanks to the C foundation. What it has is the terseness, power, and more importantly, it makes the actual act of hacking a joy.

As elegant as Haskell’s purely functional foundation is, it can really complicate simple, crucial, impure tasks like writing to files or talking over a network.

Monads are Haskell’s answer to this, but they often feel like a heavy abstraction tax; they allow you to write useful software, but they rarely make it intuitive or fast to prototype.

These kind of heavy-handed abstractions are in my opinion really beautiful, but not justifiable for most projects. Please do ask yourself, do I really need a functional effect system, is it worth the complexity and cognitive load? Do I really need the pure/impure computation strictness enforced at compile time? Remember that later, just adding a simple print somewhere is not going to work without refactor (welcome to the IO monad).

As a long-time Lisper, for me this is a massive barrier to usability. In many ways, you can only fix what you can observe.

Scheme happily sacrifices academic purity so you can slap a (write ...) anywhere in your code and instantly see what’s going on. I’m sure a Haskell purist is burying their face in their hands right now, citing Debug.Trace or questioning why I’d want side-effects in a lazy, well-optimized language. They aren’t technically wrong, but the friction added to quick-and-dirty debugging is a tax I am simply not willing to pay when I’m trying to move fast.


Meta-programming and DSLs  #

The second problem with Monads is directly tied to their greatest strength: they are synonymous with Domain Specific Languages (DSLs).

The promise of DSLs is fantastic—don’t write a complex program to solve a problem; write a simple program in a bespoke language designed solely for that task. Parsec is the golden child here; the parsing function is practically identical to the BNF grammar.

But the success of Parsec has filled Hackage with hundreds of bespoke DSLs for everything. One for parsing, one for XML, one for generating PDFs. Each is completely different, and each demands its own learning curve. Consider parsing XML, mutating it based on some JSON from a web API, and writing it to a PDF. In the Java ecosystem for example you expect a certain level of consistency. You pull in three libraries, and they generally follow familiar object-oriented or functional-lite conventions. But in Haskell, three DSLs designed for three different tasks usually mean the authors optimized strictly for the domain, completely ignoring syntax consistency. Instead of five minutes skimming JavaDocs, you have hours of DSL documentation and tutorials ahead of you.

As we Schemers know, Scheme is intentionally simple. That simplicity isn’t a limitation; it’s what makes it endlessly flexible.

While modern JVM languages rely heavily on reflection or complex compiler plugins (like Kotlin’s KSP) to achieve this, Lisp hackers have been effortlessly reshaping the language for decades using the powerful macro system and extending and bending the language to their will.

( define-syntax  define-repo-method
  ( syntax-rules ()
                ((_ method-name accessor docstring)
                 ( define* ( method-name repo . args)
                   docstring
                   (apply (accessor repo) args)))))

Haskell, much like Scala’s advanced type-level programming, often requires a mountain of language extensions to achieve similar flexibility ( Template Haskell and its powerful but scary API).

 {-# LANGUAGE TemplateHaskell #-}
 import  Control.Monad
 import  Language.Haskell.TH

 curryN  ::  Int  ->  Q  Exp
 curryN n  =  do
  f   <- newName  "f"
  xs  <- replicateM n (newName  "x")
   let args  = map  VarP (f :xs)
      ntup  =  TupE (map ( Just  .  VarE) xs)
  return  $  LamE args ( AppE ( VarE f) ntup)

I’ve used Scheme for countless projects because of its combination of features and philosophies that bring it to my personal “sweet spot”. It’s also an advanced language, which keeps pioneering, and of unconstrained innovation (e.g. delimited continuations). When you want to mold the syntax directly to your will, Scheme gets out of your way and helps you achieve it.

Of course, to be completely fair about my toolkit, standard Scheme can sometimes lack the heavyweight, “batteries-included” ecosystem required for massive enterprise production compared to the JVM. Also, when compared to Haskell, Lisp compilers are modest and simple, at best, but that makes them also that much more approachable (and the error messages that much friendlier).

I’m not saying Scheme is objectively better than Haskell. Languages are tools, and we should choose the right tool for the job.

I will always remember all I learnt from Haskell’s functional beauty and ideas, but to me, Haskell remains a platonic ideal of a programming language: lighting the way in a certain direction, but a bit too rigid for most of what I do.


Then there is the REPL: Interactive workflow, developer power  #

A REPL (Read-Eval-Print Loop) is an interactive environment, which can be used connected to your console, running application, language compiler and more, which gives you superpowers as an engineer 🦸🏼.

Lisp dialects, more specifically Guile Scheme, have great support for this. I personally of course like to do this with Guix, Emacs, ( Arei/Ares + sesman) you can get an ultimate extensible powerful editor experience, miles ahead of traditional IDEs 🐂 .

And no, it’s not the same kind of REPL you know from Haskell (GHCIDE or others) or Python. Lisp REPLs can do so much more and integrate seamlessly to your editor. Evaluate, check, change and debug live, seamlessly.

It fundamentally changes the development workflow by eliminating the slow edit, save, compile, run cycle. Instead of writing a whole program and then running it to see what happens, you get a fast, conversational workflow. What does this mean for in practice?

  • Incremental Development: Write, test, inspect, evaluate one function or even one line at a time. Get immediate feedback without running the entire app.
  • Powerful Debugging: Forget adding print statements and restarting. You can pause, inspect objects, change values, and even redefine a broken function on the fly to test a fix in any environment (yes even in production, while running).
  • Fast Prototyping & Learning: Instantly experiment with a new library or API. Just load it and start calling functions to see how they work, which is much faster than only reading documentation.

When integrated into your code editor, you can execute any piece of code (a line, a selection, or a file) with a keyboard shortcut and see the result instantly, creating a seamless and powerful development experience.

Overall Lisp languages are simply the sweet spot for me and of what I consider good developer experience. They also give you super powers and let you create beatiful systems that can last.

Wednesday, April 29, 2026

Monday, April 27, 2026

Arthur A. Gleckler

validate-email-address

I'm building a new web site in Scheme for BALISP, the Bay Area Lisp and Scheme Users Group. (The site isn't launched yet, but will replace the current Meetup.com redirect at balisp.org sometime before our next meeting.)

The BALISP site needs to validate users' email addresses to make sure that they comply with RFC 5322, but I couldn't find a complete validator written in Scheme. Everything I read said that making a correct validator is a surprising amount of work. Many people write a complicated regular expression that produces false positives and negatives, but that felt wrong.

Fortunately, Dominic Sayers had published a thorough set of tests as part of his isemail validator, written in PHP. With those tests and the help of Claude Code, I was able to implement a complete validator that works in Chibi Scheme and Gauche Scheme. My new Scheme library is called validate-email-address, and is licensed under the MIT license except for the test data, which are licensed under Dominic's original BSD 3-Clause license. I hope it's useful to other Scheme hackers.

by Arthur A. Gleckler at Monday, April 27, 2026

Sunday, April 26, 2026

Scheme Requests for Implementation

SRFI 267: Raw String Syntax

SRFI 267 is now in final status.

Raw strings are a lexical syntax for strings that do not interpret escapes inside of them and are useful in cases where the string data has a lot of characters such as \ or " that would otherwise have to be escaped. This SRFI proposes a raw string syntax that allows for a customized delimiter to enclose the character data. Importantly, for any string, there exists a delimiter such that the raw string using that delimiter can represent the string verbatim. The raw strings in this SRFI do not do any special whitespace handling.

by Peter McGoron at Sunday, April 26, 2026

Tuesday, April 21, 2026

spritely.institute

Spritely Goblins v0.18.0: Sleepy actors!

Goblins version 0.18.0 release art: a Spritely goblin takes a nap in a chair by a fireplace, tea steams on a nearby table

We’re excited to announce the release of Spritely Goblins 0.18.0! This release features a new caching layer called “sleepy actors”, OCapN protocol updates, and numerous bug fixes. So get cozy by the fire, pull out a steaming cup of tea, and let’s have a nice relaxing read about this exciting new Goblins release!

Sleepy actors

Remember when we introduced persistence back in Goblins 0.13.0? You’re not sure? Okay, as a quick refresher, Goblins’ persistence system is able to serialize a running Goblins program for you and wake it back up later! Pretty cool!

Goblins is pretty smart about only saving the changes that need to change. But... if we can save actors to disk, do we really need them to be “awake” all at once? What if we let them take a little nap, and just woke them up when it’s time for them to do something? Then they could go back to bed when they aren’t needed anymore!

Well that’s exactly what we’ve built! Sleepy actors are a new, optional caching layer has been added to the core of Goblins. Actors may now go to sleep or be woken up depending on a customizable caching algorithm known as a “sleep strategy”. When an actor goes to sleep, it is saved to the vat’s persistence store but its reference remains live. When an asleep actor receives a message, its state is restored from the vat’s persistence store and the message is processed as usual.

Goblins currently ships with two sleep strategies: an extremely simple strategy where your little goblins head to bed after each and every turn, and a “least recently used” algorithm, which functions as a hot cache where only the most recently activated goblins stay awake, and the rest go take a nap.

For a feature that’s so sleepy, we’re pretty wired about its potential, and we hope you are too!

OCapN protocol updates

The OCapN draft specification has changed in the time since the last Goblins release. The op:deliver-only operation has been dropped in favor of a single op:deliver operation. GC operations now accept a list of export positions instead of a single position so that GC can be done in batches; their operation names have likewise been changed to the plural form (op:gc-export is now op:gc-exports, etc.) The protocol version number has thus been bumped, which means that applications built with an earlier release of Goblins are incompatible with the OCapN shipped in this release.

Notable bug fixes

  • Fixed a race condition when restoring multiple vats from persisted data. If Alice in vat A is referenced by Bob in vat B but no other actors in vat A then it was possible for Alice to be garbage collected before vat B is restored.

  • Fixed a signing oracle vulnerability in the WebSocket netlayer’s designator authentication code.

Getting the release

This release includes all the features detailed above as well as many bug fixes. See the NEWS for more information about all of the changes.

As usual, Guix users can upgrade to 0.18.0 by running the following:

guix pull
guix install guile-goblins

Otherwise, you can find the tarball on our release page.

If you’re making something with Goblins or want to contribute to Goblins itself, be sure to join our community at community.spritely.institute! We also host regular office hours where you can come and ask questions or discuss our projects. Information about office hours is available on the forum. Thanks for following along and hope to see you there!

Thanks to our supporters

Your support makes our work possible! If you like what we do, please consider becoming a Spritely supporter today!

Diamond tier

  • Aeva Palecek
  • Holmes Wilson
  • Lassi Kiuru

Gold tier

  • Juan Lizarraga Cubillos

Silver tier

  • Austin Robinson
  • Brit Butler
  • Charlie McMackin
  • Dan Connolly
  • Deb Nicholson
  • Evangelo Stavro Prodromou
  • Glenn Thompson
  • James Luke
  • Jonathan Wright
  • Michel Lind
  • Mike Ledoux
  • Nia Bickford
  • Steve Sprang
  • Travis Smith

Bronze tier

  • Alan Zimmerman
  • BJ Bolender
  • Ben Hamill
  • Benjamin Grimm-Lebsanft
  • Brooke Vibber
  • Brooklyn Zelenka
  • Crazypedia No
  • Ellie High
  • François Joulaud
  • Gerome Bochmann
  • Grant Gould
  • Gregory Buhtz
  • Ivan Sagalaev
  • Jason Wodicka
  • Jeff Forcier
  • Marty McGuire
  • Mason DeVries
  • Michael Orbinpost
  • Neil Brudnak
  • Nelson Pavlosky
  • Philipp Nassua
  • Robin Heggelund Hansen
  • Ron Welch
  • Stephen Herrick
  • Steven De Herdt
  • Tamara Schmitz
  • Thomas Talbot
  • William Murphy
  • a b
  • r g
  • terra tauri

by Dave Thompson and Christine Lemmer-Webber at Tuesday, April 21, 2026

Saturday, April 11, 2026

Idiomdrottning

What Delta Chat was

Being able to quickly write replies to email, real actual email, was very valuable. That was the core of what drew me to Delta Chat.

There are plenty of proprietary email apps set up around that feature but in the free world, not so much. Delta Chat was it and it was a gem because it was in many ways better than those other sparks and spikes and whatever they were called. Not to mention the incredible leap of faith it takes to go for a proprietary mail app since they can read the emails.

Delta Chat is rapidly moving away from being usable for that. If someone forks it or finds a good alternative (that’s FOSS, obvs), I would love to know.

I know I’ve worked a little on Notmuch, and I’ve talked a little bit with the people who make aerc, but for all their conveniences they’re still traditional mail apps where the threads look like files that you have to open up and enter into and work with. The few extra clicks involved with using a normal mail app might sound like no big deal but it really adds up. All the opening, searching, archiving, threads management… Whereas with Delta Chat in its prime, you just see the message right away and can reply right away. Easy peasy.

Maybe K-9 but it got bought out by Mozilla and they hate autocrypt which I don’t. I think WKD is better, sure, but I try to use both. K-9 used to be one of the best autocrypt clients out there.

by Idiomdrottning at Saturday, April 11, 2026