Peter Bex on CHICKEN Scheme

Sep 2026 - Alex AlejandrePeter Bex (website) is a CHICKEN scheme maintainer and professional Clojure developer. We got to know each other on IRC over a few months and discussed:CHICKEN Scheme and its 6.0.0 releaseScheme’s community and standardization processPostgres, the horrors of MySQL and (default) SQLiteClojureMy ongoing core contributions mainly focus on the numerical tower code, keeping the in-core copy of the irregex library up-to-date with the upstream version (of which I’m a co-maintainer), squashing bugs and the odd security fix. I enjoy deep diving into odd corners of a code base to get a better understanding and then improve any weirdnesses I find. - His CHICKEN AboutBeginningsHow’d you start computing?I started computing when I got an old hand-me-down C64 which came with a “learn BASIC” book targeted at kids. Of course, I wanted to write my own computer games (which I never ended up doing). Later I got a real PC for my birthday and discovered my BASIC knowledge sort of transferred (with QBASIC in DOS).Later, I learned about C, which I used for many years until at uni there was a course which taught Lisp (Scheme, really). We started with The Little Lisper/Schemer, and then SICP. I had a “functional programming course” before that which I almost flunked because it just didn’t make any sense (they used Concurrent Clean, because obviously teachers use their own language to teach regardless of its qualities - a common fault in academia). But the Little Schemer finally made it click. The teacher also showed how to implement objects using nothing but lambdas which I found awesome.I actually studied AI before all the LLM bullshit. I much preferred the cleverness of the classical AI algorithms like A* search and genetic algorithms, but I haven’t really used them much in practice, only for my studies. I keep thinking I should use a GA for something, but no real use case so far. But even back then it was clear that neural networks were the future, though I found them boring because it’s just a bit of math (which I initially barely understood) and it’s basically a black box. I’m still grateful I studied AI because that’s the reason I came into contact with Lisp.I might’ve looked into Lisp myself at some point (having been curious about it as one of the “foundational languages”), but I might not have had sufficient gumption to really dig in. After uni I got a job where they were using Rails in those somewhat early days (2006), so I learned Ruby as well. I liked learning Ruby and thought it was cool to see the power of Rails, but later got very frustrated with it because Rails really has strong opinions and my programming style didn’t seem fully compatible with it.CHICKEN & SchemeWhy CHICKEN?After that course, I tried using Lisp for every personal project. I first started with Scheme48 but it wasn’t very practical (though very elegant). I remember running into problems with the image not being big enough, running out of memory. I never really liked PLT Scheme (now Racket), coming into first contact with it through DrRacket, which felt very sluggish to me, though I do think DrRacket’s a cool alternative view of what an IDE could do. For example, when you hover over a variable and it shows you a line pointing to the origin of that variable.CHICKEN was a practical and fast system, with a good community and acceptable license (I had quite a distaste for GPL at the time). CHICKEN is also one of two (as far as we know) implementations that use the Cheney on the MTA technique explained here. There were lots of rough edges, but I think wanting to address those is what enabled me to get so deep into the core. If everything is perfect, there’s not much to do, really!So I started contributing to CHICKEN with some modest eggs (CHICKEN packages) at first, and eventually the core system. I mostly learned about Lisp internals by doing, mucking around with the CHICKEN core and trying things. I read Queinnec’s Lisp in Small Pieces, which deals with translation to C but leaves a lot undiscussed and distracts with OOP-heaviness. SICP has some good material. Then there’s Appel’s Compiling with Continuations, which is really short and to the point but still manages to be rather comprehensive; I love books like that.In general, I just enjoy hacking on the core, even if I don’t have that much time to do so these days. I have to stress that I’m a slow learner. Building my understanding of CHICKEN was a process of many many years, and there are still parts of the system I’m not that familiar with (although I know my way around enough to get up to speed if needed).What do those Lisp books lack?Compiling with Continuations has only a brief section on the runtime system, so it doesn’t go very deeply into e.g. garbage collection and data representation. Lisp in Small Pieces doesn’t go into continuation passing style, IIRC. And its data representation isn’t very optimized. I like to blog about cool techniques that are undiscussed nowadays. For example implementing weak references and how to GC them efficiently. Other stuff I rarely see discussed is how to do FFI and cross-module optimizations, separate compilation and cross-compilation (which only a handful of Schemes even support) etc.What’s Scheme to you?In general, Scheme, to me, is a very clean language with a minimal core which facilitates experimentation. This is the fundamental tension of the standardization process - production-quality Schemes tend to grow in size, and there is value in standardizing that. But that also takes away the minimalism which makes experimental implementations possible. For example, Felix Winkelmann (@Bunny351, CHICKEN’s original author’s talk about Scheme implementation) once started a Common Lisp (subset) implementation where he experimented a lot with types and flow analysis, resulting in CHICKEN’s type stuff.What are your thoughts on the overall Scheme ecosystem, R7RS, SRFIs vs. implementation-specific libraries etc.? A few implementations don’t seem to care anymore.I think the split of R7RS into a small and large language was the right thing to do, as R6RS was reviled by minimalists and found lacking by maximalists. In general, I’m a bit sad for R7RS - if some of the bigger community Schemes are essentially completely ignoring it, they’re doing something wrong IMO. Many, maybe even most Scheme implementations are essentially one-man shows. I suppose CHICKEN is also turning that way again, since we have lost quite a few contributors (mostly due to changing life situations) and it’s hard to attract new ones.At the same time, the R7RS “large” project sort of went off the deep end, doing its thing without really caring about community buy-in. The churn of the R7RS large is also a bit too fast to keep up with. They’ve pumped out tons of SRFIs in a few years (actually, looking back at it right now it doesn’t appear like it’s that much, but it is certainly a lot faster than SRFIs used to be.) The SRFI process is open to submissions from literally anyone, for better or worse. I’ve noticed there have been a few new contributors to CHICKEN who submitted implementations for some of the newer SRFIs, so that’s good and I’m happy at least some people are bothering to do this.CHICKEN 6 is base R7RS, but older CHICKEN code will keep working. We still support the old module syntax (which is the “native” one). The R7RS library declaration is essentially syntactic sugar for the core module syntax. R7RS-small is almost fully backwards compatible with R5RS, so there is no conflict there. Porting an egg to CHICKEN 6 usually requires only a few small adjustments because some (non R5RS) identifiers moved around between modules to better fit the R7RS style.What’s CHICKEN’s development process like?CHICKEN 4 was “hygienic CHICKEN”, which introduced the module system (and required overhauling the expander). This was all Felix, requiring a lot of deep internal knowledge about how macros interact with modules etc.CHICKEN 5 was a community effort through and through. It was mostly a sanity and cleanup release where we did a massive reorganization of the modules (what lives where) to make it logical and matching R7RS a bit better. We discussed this during an IRL meetup and continued for the months after. (Community is a strong advantage of CHICKEN!) We also added a numeric tower.CHICKEN 6 was basically cut off from Felix’s branch to make UTF-8 handling sane and consistent (like Python 2 -> 3, but way less disruptive.) There’s a strict separation between strings and bytevectors, with changes to ports and other I/O as well. We took the opportunity to integrate the R7RS egg into core so it’s more “native”. Strings in the FFI should be more efficient because there’s no needless copying anymore.CHICKEN 6.0.0 was held back by a bug causing heap corruptions (do view the patch’s description!). We had been looking in the completely wrong spot. These heap corruptions appeared somewhat randomly, but only with the CHICKEN wiki server, not with the plain web server serving simple files or even the entire Awful framework. We strongly suspected the Subversion client library (which the wiki uses as a backing store for the content), and we’d found other issues in there as well (it’s kind of hairy callback-heavy code due to the design of libsvn).The wiki is a rather small program and the rest of the web stack seemed to be fine, so we suspected the svn client lib. But I whittled down the code of the wiki to almost nothing and it was still failing. When I commented out the URI normalization code (you get redirected when opening a page that’s behind a symlink, so as to get a canonical URL that points to the original file) it suddenly stopped crashing!That normalization code didn’t appear to do all that much, so we quickly pinpointed it to be read-symbolic-link. A quick glance at the code in the core system confirmed it was totally borked because of a change made for CHICKEN 6’s UTF-8 transition.Now