Igropyr

Origins

The Igropyr project contains two parts: Igropyr on the server, and Goeteia in the browser.

Igropyr began in 2018. Out of love for Scheme, I was looking for a modern Scheme web server I could actually run in production — not a proof of concept content to stay in academia — and I found nothing.

Back then, and still today, Scheme web servers stop at raw string concatenation to build a request and its response. They lack the modern conveniences — proper JSON responses, concurrency, asynchrony, and the like — that a real application backend needs.

So I improvised. I tried Apache calling out to CGI. Then, inspired by Node, I wrote a first thin wrapper over libuv. That was Igropyr's earliest prototype.

In the years that followed I came to know Erlang, and took its ideas to heart: message passing, and let it crash. Around that time Swish had built the earliest Erlang-style system on Chez Scheme — but its network programming still lived in that same primitive, string-concatenation world.

Swish is what convinced me. Inspired by it, I decided to rebuild Igropyr from the ground up.

Today Igropyr goes further than that Erlang prototype ever did. When a handler crashes or a request times out, the server can tell the client that the request went wrong — and hand the choice back to it: retry, retry with different parameters, or stop. In practice this shortens how long a user waits, and it makes server-side failures invisible from the user's side.

And it carries messages as s-expressions themselves: when both ends speak Scheme, a request and its reply need no codec at all — the data crosses the wire as it is, exact numbers intact. Scheme, at last, has a JSON of its own.

It even supports continuation-based web programming — the functional community's most beautiful daydream. It is no fit for an ordinary form-filling page, but where the work is strongly transactional it lets a single transaction stretch across the wire, held open between the server and the remote client.

By now Igropyr carries everything a modern web server is expected to have: JWT, non-blocking Redis and database clients, a self-forming cluster, hot code swapping, and even BLAS-accelerated vector search…

Goeteia came from another daydream — writing the front end in pure Scheme as well. I tried the existing Scheme-to-JavaScript compilers first, but building on WebAssembly turned out to be the better foundation — and in the end it cost me nothing on the JavaScript side either: the same source compiles to both, so a browser too old for WebAssembly GC still gets the page, running a JavaScript twin that nobody has to keep in step because it is generated, never written.

Goeteia, for its part, is a compiler just 50 kB, running right in the browser, and heavily optimized for 3D. It renders dazzling web effects from Scheme straight to the page on the fly, or precompiles them for more speed and optimization, and it supports programming web games. It also takes a fresh approach to the DOM — in this post-virtual-DOM-tree era, a distinctly Scheme one: macro-based DOM state management, and pretext effects.

Goeteia now has gone further than I planned for it. Everything about it is small — a compile takes a moment, a check needs no eyes and no graphics card, only arithmetic — and small things can be run side by side, so it drives its AI pipelines many at a time. Each one takes a piece of video and lifts out a skeleton, its textures, its skinning, its motion: work that used to want a capture stage and someone in a suit, and now wants only footage.

AI is already fluent at the reference imagery — the designs, the turntables, the motion video; what was missing was the road from those images to finished 3D. This is that last piece of the puzzle. And like every AI, it does not arrive in a single pass; it closes on its target by going round again, and again, until the program says it came out right.

The project is entirely open source, free for any use — commercial included. I hope you enjoy it.