2023 is over, what's with the silence?

Blog has been terribly quiet, is Flower dead?

No! Quite the contrary.

Flower didn't meet its goals in 2022, or in 2023. But both of those years pushed it a lot forward. A lot of work has happened, especially in November and December of 2023. I just thought most of it wouldn't be very interesting to read about since there was a lot of refactoring, redesigning and organising. None of which I thought would make a good post in itself.

All in all, since last update there have been 105 commits to the project. That's too many for me to list the more detailed stats, but there's been around 13000 insertions and 4160 deletions to the codebase. So, definitely not dead.

Starting to stabilise the syntax

Some of the syntax is starting to stabilise. With the exception of generics and assignments, a lot of the syntax is now at least stable-ish. Which means I might be able to show more Flower source-code in the blog as well! This is something from the current test suite for an example

def simple_sum : func(s32 lhs, s32 rhs) -> s32 as {
    return lhs + rhs;
}

def main : func () -> s32 as {
    return simple_sum(14, 32);
}

Tooling-induced redesign

I knew I wanted to support tooling pretty early with minimum code changes, so most of the code was built as libraries already. At october-ish 2023 I decided that to onboard people I wanted to have some tooling available from the get go. Since most of the stuff works with language servers, that was an obvious starting point.

So, after working on a language server for Flower for a bit to get things such as semantic syntax highlights in place some cracks started to show in my design. This was expected, and nothing too major since I had anticipated it and done some mitigation beforehand. But it required reworking symbol handling, adding some internal name-manging, and a bunch of other stuff.

None of these are visible to the user, of course. Which is why I didn't think it would be too exciting to write about individually. But it means the foundations are starting to finally be in place.

Improved internal compiler tests

I also started using more internal test cases for the compiler. doctest is nice in that it allows me to write the tests to the file being tested, without blowing up my compile times. This reduces the problem of symbol visibility and can now be toggled off entirely with a preprocessor define.

All in all, a good improvement to the codebase quality.

Planning for bringing some people along

Yes, I mentioned onboarding before. I planned to start opening up the project for more people to contribute to, probably starting with recruiting a couple of friends or coworkers or somebody with interest, not yet opening everything to the public. But there's a bunch to do before I get to that.

Core features in place

There are still some core features that I need to get into a more complete state before thinking of bringing people along. Namely, more complete branching and variable support. What it means is that I want these to be compiled to a Flower bytecode file and have the virtual machine able to run them without problems. Simple jumps and function calls already are in place, but conditional branching or variable support are not really anything more than a sketch (as in, it's "I wrote this in a day without thinking" -quality feature at the moment). How variables are handled especially needs some work, branching seems to be working pretty well with the day-one-implementation for now.

Forgejo and Documentation

I'd say a lot of my time in the recent months working with Flower has been documentation work. I set up a forgejo repository in codeberg and have started to use the issue board there for organisation. In addition to documenting the issues, there's been a work to have some kind of onboarding documentation that I find woefully lacking in many projects. Including (especially?) at actual paid-work projects. Trying to make that a bit better should be at least somewhat a priority. (And one of the reasons I want few friends/coworkers to tag along first, so I can use them as guinea pigs on how hard it is to get to know the project from inside.)

Licensing

And then there's the legal parts. Opening code to external contributions means licences and copyright become a thing since everything won't be my code (or text) anymore. Having been around in the open-source world for a good while, I'm no stranger to licences at this point. Since I want people to know what they're contributing to from the get go, and really don't want to have to deal with relicensing issues later on myself, I kinda want to have this to be in place from the get go.

The goal is to have the compiler infrastructure itself, the library parts, and the specification licensed under somewhat different terms. For now I've been thinking about a combination of EUPL v1.2 (or later), Apache 2.0 with LLVM exceptions and CC-BY-ND-4.0.

So yeah, there's been a lot to do to start opening the project up. I would love to say I get to do it in the spring, but considering my current track record with estimations, I'd not hold my breath.