What’s MyFPL?

Meinte Boersma

— 3 min read
Share

(FPL stands for Functional Programming Language — see also this Wikipedia article)

In October 2024, I gave a talk at the 2024 edition of the LangDev conference, titled “GenFPL: DSL-embeddable functional programming languages”. You can find the abstract of the talk, a video registration of it, and the slides for it here.

The subject of the talk was GenFPL, a tool to generate functional programming languages from a configuration, with the intention to embed such FPLs in DSLs. I started creating this tool partly as a use – and show – case for LionWeb, partly as a vehicle for talks/presentations, partly to scratch my own itches, and partly because I genuinely think this would be useful. (Indeed, these reasons are pretty much in order of decreasing importance.)

Since then, both available time on my side and interest from our – granted: tiny – language engineering community has been lacking, so there hasn’t been any progress on GenFPL since I gave the talk. I also realized I broke the “don’t abstract before you did it concretely thrice” rule: before you try to abstract (or “go meta” on) anything, you should have implemented at least three instances of it by hand, in the most straightforward way possible.

This state of affairs is of course wholly unsatisfactory. Lack of time on my part prevents me from resurrecting GenFPL in full. What I can do is slowly implement and evolve my own FPL “in the open”. That may even be more useful, because it might be more clearly of interest to a wider audience than just the language engineering community.

So, that’s what I’m going to do: I’ll publish a series of blog posts about the implementation and evolution of my own FPL, (completely unoriginally-)named “MyFPL”.

💡
The implementation can also be found on Codeberg: https://codeberg.org/dslmeinte/my-fpl

For the implementation, I’ll also stay pretty close to the mold used in my book Building User-Friendly DSLs, published by Manning. That means, I’ll use the terminology and conceptual framework introduced and used in that book.

In particular, I’ll consider the AST – the Abstract Syntax Tree – as the authoritative source of code, instead of some concrete syntax for it. I won’t use a grammar to implement a textual concrete syntax — as is often customary in the PL community. Instead, I’ll use the projectional editing paradigm to provide a nice concrete syntax, that’s still rather text-like.

💡
This blog series will not be a rehashing of my book. There will be some overlap, and some content will extend on the book’s contents, but the blog series and book serve quite different goals. Also: this blog series will assume some pre-existing familiarity with software language engineering. I’ll explain the most important terms, but generally briefly.

In contrast to my book I’ll be using TypeScript instead of JavaScript as the implementation language. I figured a series of blog posts affords me the extra space and time to write type-checkable code. I’ll also be relying heavily on LionWeb as a framework for formalizing a metamodel, and materializing (and persisting) ASTs conforming to that. (Full disclosure: I’m one of the core members of the LionWeb team.)

Besides describing the implementation, I’ll also discuss design decisions — which are hopefully even more insightful than the implementation itself. The FPL is not going to be…“standard” in any way: I have some ideas about what a FPL should be and should be able to provide to the programmer/developer that I don’t see in existing languages. Retro-fitting such ideas into some existing language might be possible, but it’d always be a bit of an ungainly hack. Starting a projectional language from scratch allows me to implement these ideas cleanly and clearly.

As for the frequency of this blog series: I’d love to be able to guarantee publishing a next installment every week, but currently I’m just not able to hold myself to such a promise. I’ve built up a bit of a buffer, having already prepared a couple of blog posts ahead of time, so things might not be entirely bleak. Each blog post will be relatively short: typically adding one small(-ish) language feature, discussing one particular aspect, or giving a “helicopter view” with the details coming a later blog post.

Also expect some meandering. I’m implementing the language more-or-less as I go, so I might very well go back on earlier decisions and rework certain parts and aspects of their implementation. I think that should be nicely illustrative of how software language evolution works in practice, and is more insightful than a completely pre-planned evolutionary path.

In any case, stay tuned for more…

💡
At no point will I be using (Gen)AI to write this blog series, or “outsource” coding duties to.
💡
In this blog post, I explained what I’m envisioning for MyFPL. In the next blog post, I’ll explain why exactly I want to implement MyFPL.

Read more