Aspect of MyFPL

Meinte Boersma

— 3 min read
Share
đź’ˇ
This is post 03 in my blog series on MyFPL — see the index/table of contents.

The code in this and previous blog posts can also be found here, on Codeberg. Check out the repo at the commit marked “blog 03”.

Before I actually – really!, finally! – start implementing something, I want to set the stage a little bit. This should help with understanding what all the various bits of the implementation are supposed to achieve — especially as we’ll be evolving and adding to the implementation by tiny bits across the whole landscape.

In my book Building User-Friendly DSLs, I identify four key aspects of any DSL:

Structure

Governs the structure of ASTs representing DSL content — AKA the metamodel.

Notation

The concrete syntax â€“ or multiple syntaxes! — used to represent such ASTs.

Constraints

Rules that determine whether a given AST is concerned to be valid â€” including sensible and helpful messages reported back to the DSL’s users when these rules are violated. This aspect typically also involves defining and implementing a type system for the DSL.

Meaning

What an AST in the DSL means in terms of it being executed some way — AKA the DSL’s semantics. (I have a sort-of “laissez-faire” relation with that word, by the way, so don’t expect anything formal there. I’ll get into that a little more below.)

I’ll explain these aspects in a lot more detail in the course of this blog. Here’s a diagram of the key aspects described above:

Diagram of the four key aspect of MyFPL, and their relations

This diagram also hints at a couple of relations between some of these aspects that weren’t explained in the enumeration above:

  • DSL content gets executed in an Execution environment, either through direct interpretation, or after generating code and deploying that generated code somewhere and somehow.
  • The behavior of this execution is what I deem to be the DSL’s semantics — AKA its meaning.
    I’m aware this is a non-standard way of thinking about semantics. “Usually,” there’s some formalism to define a language’s semantics upfront, after which we proceed to implement that definition — hopefully faithfully and completely! Here, I effectively take an implementation of the semantics – in the form of the “execute” arrow in the diagram –, run it against DSL content, and declare whatever behavior it has as being the semantics of the DSL.
    That also means that as soon as the implementation of the semantics changes – or is swapped out for another one – the DSL’s semantics might change! If we have multiple implementations of the semantics, those semantics might actually be different — hopefully intentionally so! In the case of MyFPL, we’ll have just one implementation of the semantics.
đź’ˇ
By the way: the above remains true when we substitute “DSL” with the more general term “software language”. That term encompasses both DSLs, modeling languages, and any programming language including any FPL.

Most of the implementation of MyFPL will be directly part of exactly one of these key aspects. A small part of the implementation will not be part of any of these key aspects, such as:

  1. Entrypoints for a front- and backend.
  2. Configuration of the development environment, and building the FPL in the sense of “compiling” — or “transpiling” as it’s supposed to be called for TypeScript.
  3. Unit tests — (insofar I actually care to write those…)

(If we want to be fancy, we could say that part consists of “orthogonal boilerplate (code)”.) We’ll write most this during the setup phase, after which it will remain largely unaltered for the rest of the journey.

đź’ˇ
In this blog post, I’ve explained the four key aspects of MyFPL. In the next blog post, we’ll set up the development environment to implement MyFPL with.

© 2026 Meinte Boersma (DSL Consultancy)

Read more