Passerine
I’ve decided to group my thoughts about language design with regards to Passerine specifically under this section. What’s Passerine? I’m glad you asked! It’s a compiled programming language I’ve been working on for about a year-and-a-half, in the vein of OCaml and Scheme. If you’re a fan of macros, continuations, and type theory, you should enjoy some of these posts:
Macros, Types, and Next Steps
2021-06-01 · About 11 minutes long
Passerine is at an interesting point: we’ve established a few language features, and built this easily extensible functional core on which to base the rest of the language. We currently have two implementations of the language, one written in Rust, the other in D, and it’s imperative we set the course of the language before divergence occurs.
Vaporization and Modern Memory Management
2021-02-24 · About 17 minutes long
Note
This piece is a work in progress.
An interesting design space in the field of programming language design is that of memory management. In short, programs produce data while running. This in of itself isn’t much of a problem: in fact, it’s a good thing! If your programming language doesn’t allow for the production of any useful data, you might want to take a closer look at it…
As time goes on, our program may no longer needs certain data. We could just leave this garbage floating around forever, but, alas computers a finite amount of space to work with. It’s trivial to produce useful data; the more difficult task is figuring out when it’s no longer needed.
All You Need are Coroutines and Pattern Matching
2020-07-10 · About 7 minutes long
Note
This is an old post I wrote a while back. My opinions on the subject have changed slightly but this post has historical merit. The date is not entirely accurate, this article coincides with around the time I started seriously implementing Passerine.
Abstract
The average programmer just wants to write code [citation needed]. Language designers, on the other hand, want to write code, that is, programming languages. Ever since the first lisp interpreter sputtered through it’s first s-exp, there’s been a quest to build a ‘perfect’ programming language. The field of language design remains open, at least in the sense that a better language can always be built. No matter how hard you try, there is no language that won’t make you clarify your ideas.
Architecting Asynchronous Schedulers
2020-07-10 · About 8 minutes long
Note
This post explores one design methodology for asynchronous schedulers in the context of a language that is maximally asynchronous, i.e. everything is executed asynchronously. This post is largely a reflection of trying to grapple with this blog post about Tokio’s scheduler