Adrian Sampson's article Flattening ASTs (and Other Compiler Data Structures) was a great read and reminded me that I often make problems bigger than they need to be. I was chasing this ridiculous floating point NAN approach and didn't stop to think about how that was slowing me down.

On my new branch, I now have object types and a working generator. I originally tried to play with a doubly-nested set of interfaces so that the outer type represents the Code type and the inner type represents the Object type. The problem is that I was hitting an error with Golang's generics where interfaces can't be used for derived types. Look at this example in the Go Playground.

./prog.go:45:24: cannot use red (variable of type RedCar[Dynamite]) as TrainCar[Loadable] value in argument to append: RedCar[Dynamite] does not implement TrainCar[Loadable] (wrong type for method GetTarget)
		have GetTarget() Dynamite
		want GetTarget() Loadable
./prog.go:45:29: cannot use blue (variable of type BlueCar[Passengers]) as TrainCar[Loadable] value in argument to append: BlueCar[Passengers] does not implement TrainCar[Loadable] (wrong type for method GetTarget)
		have GetTarget() Passengers
		want GetTarget() Loadable

Because of this, I had to do a small rewrite (smaller than I anticipated) and now it is satisfing all errors and prints the code and value to the console.

There is a ton more to do just for feature parity with the old but I am making much faster proces thjan previously.

In order to get maps ready to go, I need to also have the working legend system and that also requires a meta-legend and I am still not sure how to best organize the code.

The issue is because I have this intermediate understanding of the Self architecture and I am trying to mirror that in Rhumb but also through the lens of Go. It doesn't help that I spent a month away from the codebase and my Go familiarity is mediocre at best. So it's taking some time to get back up to speed one exactly where I left off and how I can carry the work foward.

That's all that I can really say until I've gotten more stuck-in. See you all in the next one!

Now, where were we? Oh yeah! Rhumb! You will learn more about the language in many more posts to come. Keep reading for insights into the current status and rough roadmap for the year ahead.

The site is barebones and many pages aren't filled out but I do have a fair amount of content already mostly there. It just needs to get organized from my horrible smattering of notes.

That said, the language itself is not quite up to snuff. I am doing this documentation exercise to get myself back into the right frame of mind to begin development again.

Where is it at currently?​

The language can compile basic labels and do basic math. That's about it. Maps are my next step and I want to make sure I get all the pieces right so that they don't require any re-working later. This bit of code will be the foundation for pretty much everything else that follows, data-wise.

Once maps are done, my plan is to first do simple selectors (enough to accomplish basic conditional functionality), then to functions and strings. After that, likely I will need to do another refinement pass on maps and make sure the protype system is bug-free.

Once all of that work is done I want to do another release and polish and expand the CLI and tooling support.

After that, I will go to signal selectors, libraries, and other tooling.

How long will that take?​

Likely more than a year. I work full time, have a girlfriend, a son, and several other hobbies. Often times, I wait for my interest to pique and then try to put in as much time as possible. I have a tendency to burn out and need recharges on programming due to cramming and life encroachment. At some point, if the interest is there and the language feels far enough along, I may take some time off to work on Rhumb so that I can improve the velocity but it's way too early for that kind of thing.

Expect more blog posts about design choices and novel elements of Rhumb.

Thanks for reading!