ELI5: What are the ramifications of the new Chez Scheme back-end?

harryprayiv · August 16, 2024, 7:51pm

I am all-in on Purescript despite an absolute bear of a time learning the quirks of this ecosystem. Recently, I saw that we have a new experimental back end that leverages Chez Scheme. I had no idea about Chez Scheme but this news put it on my radar and I researched it and instantly loved what I saw.

In updating my Purescript devenv this week, I decided to try using the experimental back end to compile a hello world but was hit with some warnings. In starting an issue on github, I realized I was testing purescm in an inintended way and of course I would get issues…so I just cancelled it. This leads me here where I thought it might be nice to externalize the myriad questions (and hopes perhaps) I have about it.

Please forgive me if any of these are foolish questions.:

What are the ramifications for the Chez Scheme back-end in the Purescript ecosystem? Will it simply replace Haskell as our the back end for Purescript’s compiler? That’s fine (and it honestly seems like an exceptionally wise decision) but perhaps I have mistakenly expected us to also be able to leverage Chez Scheme as an alternative to node perhaps?..

but then again, this starts to make me wonder if I don’t know anything at all (I am a C++/Haskell kind of person and web dev can be counter-intuitive to me at the moment) and someone could kindly educate me.

My thought was, if I could have a Haskell-like language that can work nearly bare metal on Cisco hardware, leveraging hardware parallelism, that is a game-changer. but maybe I am missing something and my confusion could help others to learn about PS.

antti · August 17, 2024, 6:41pm

One of the goals of the purescm backend is to be able to write the Purescript compiler itself using it, but it’s a long term goal so we haven’t really talked about it much yet because it’s still early days for purescm.

Other than PS-in-PS Chez allows native threads as you mention, and it has a great C FFI which brings many possibilities. On the other hand the Scheme and Chez ecosystems don’t provide that many libraries so things like async-io and web servers and things like that are potentially more work.

I don’t think you are missing anything. Sorry there isn’t much documentation yet - we’re sort of still trying to experiment and implement the basic stuff like strings and other data structures. I wouldn’t use it yet for anything serious - for example it doesn’t support incremental compilation yet, so you’d be compiling your whole program every time there is a code change.

Contributions are very welcome!

harryprayiv · August 20, 2024, 8:06am

Thanks so much. Hopefully as this evolves, it will bring more people to this ecosystem. Purescript, IMO, currently stands alone as the language that has almost everything I want while also being able to be run just about anywhere that I’d want to run software.

harryprayiv · February 15, 2026, 9:41pm

I’ve now experienced first-hand the ramifications of using the Chez Scheme back end. And it is pretty pretty prettttty GOOD.

I was able to squeeze a LOT more performance than is even possible using the NodeJS backend.

A comparison against JS implementations on the same machine:

Implementation	SHA3-256 1 MiB
Chez Scheme FFI (my chez-scheme branch)	50.4 MB/s
js-sha3 (fully unrolled JS)	~48 MB/s
Node.js FFI (my main branch)	28.1 MB/s
noble/hashes (loop-based JS)	~18 MB/s

harryprayiv · February 16, 2026, 10:30pm

The bottleneck now seems to be ByteVectors. I’ll be looking into this as it seems relatively easy to add them to the Chez Scheme backend.

Edit: and here’s the pull request

I’d be honored if someone would give this a look and (if necessary) brutally dunk on me if this seems like a frivolous or unneeded change.

github.com/purescm/purescm

Adding Bytevectors

purescm:master ← rowtype-yoga:bytevector

opened 03:21PM - 19 Feb 26 UTC

harryprayiv

+630 -76

Added bytevectors to try and get more performance out of my sha2 and sha3 puresc…m implementations. It didn't help in my test cases/benchmarks, but this change passes all tests and (IMO) adds much needed functionality. I also added a version bump to reflect this difference. PureScript’s `Array Int` compiles to SRFI 214 flexvectors, so every byte is a boxed Scheme object. On 64-bit Chez that’s roughly 8 bytes per element. A million bytes stored as `Array Int` eats ~8 MB of heap when the same data in a bytevector would be 1 MB. I’ve been writing crypto libraries for purescm (SHA-3, SHA-2 and HMAC) and every one of them ends up declaring its own opaque `ByteArray` backed by Chez bytevectors: ```purescript foreign import data ByteArray :: Type foreign import arrayToByteArray :: Array Int -> ByteArray foreign import byteArrayToArray :: ByteArray -> Array Int ``` ```scheme (define arrayToByteArray (lambda (fv) (bv-from-flexvector fv))) (define byteArrayToArray (lambda (bv) (bv-to-flexvector bv))) ``` This same boilerplate shows up in every library that touches bytes. And the `ByteArray` types are all incompatible at the PureScript level even though they’re literally the same Chez bytevector at runtime. The JS backend solved this years ago with `node-buffer`. There’s one shared `Buffer` type and everyone uses it. We don’t have an equivalent. There’s also a conversion cost that’s easy to miss. The string path is fine because `string->utf8` is a Chez builtin that returns a bytevector directly. But `Array Int` input has to go through flexvector -> bytevector (element by element copy) -> do the actual work -> bytevector -> flexvector (element by element copy back). Two full traversals just to cross the type boundary. In my crypto benchmarks this doesn’t dominate because the hash computation is the bottleneck, but for something like shuffling binary data between a database driver and a serialization library it’s pure waste. The other issue is ecosystem interop. Every Chez library that handles binary data speaks bytevector: file I/O, sockets, CBOR, compression, database wire protocols. Without a shared type, each purescm binding has to write its own conversion layer. `(purescm bytevector)` already has the Scheme-side utilities (`bv-from-flexvector`, `bv-to-flexvector`, `bv-to-hex`, `bv-from-hex`). What’s missing is a PureScript-level package that libraries can depend on instead of each declaring their own private `ByteArray`. That would let you pipe output from one library into another without round-tripping through `Array Int`.

Edit: Glad to get a reply so quickly. I’ll instead be building this as a module/add-on to help make this the canonical way that we wire into bytevectors via Purescript FFI.