Tech note (or horror story): the implementation guide's code at the bottom, which is also the code used to implement the diagrams on the the main page, is generated.
I start with hex algorithms written in Haxe. I use Haxe's macro system to turn this into an abstract syntax tree. I then use Haxe's ADT + pattern matching to transform this into a different syntax tree. And then I again use Haxe's ADT + pattern matching to transform this into Python, C++, JavaScript, C#, TypeScript, Lua, Java, and Haxe code. (I also have partial support for Rust and Lisp)
Unlike most "transpilers" I'm trying to generate code that looks reasonably idiomatic for the target language. I transform names and structure (e.g. `hex_add()` for a C global function but `Hex.add()` for a Java class method) and also transform for dynamic types (e.g. Point(x,y) can have numbers in JavaScript but I need a separate Point and FloatPoint for int/float in C++). This means I need to sometimes annotate the original Haxe-syntax code with hints about how it should translate into each language. For example, 1/2 produces a different value in Python (0.5) than in C (0), so I need to add hints to tell the transform code which one I mean.
I also translate the unit tests in this way, and run them as part of the output code.
It's been a fun project but it's grown out of hand. The past week I've been pondering refactoring parts of it.
The reason for all this complexity is that my original goal was to add a language drop-down on the implementation guide page. Then you could read the implementation guide in your choice of language, your choice of grid, your choice of indentation, etc. That was an overly ambitious project :-)
Thanks a lot for your work :)) It was very helpful when I tried to implement a simple version of Settlers of Catan.
But more importantly, reading/interacting with your work is fun! It enthused me to tinker with the concepts and even to try and go beyond the explained theory and think of other ways to tile, encode maps, represent coordinates, etc.
I could get enthusiastic about almost any subject if it's presented this well.
I start with hex algorithms written in Haxe. I use Haxe's macro system to turn this into an abstract syntax tree. I then use Haxe's ADT + pattern matching to transform this into a different syntax tree. And then I again use Haxe's ADT + pattern matching to transform this into Python, C++, JavaScript, C#, TypeScript, Lua, Java, and Haxe code. (I also have partial support for Rust and Lisp)
Unlike most "transpilers" I'm trying to generate code that looks reasonably idiomatic for the target language. I transform names and structure (e.g. `hex_add()` for a C global function but `Hex.add()` for a Java class method) and also transform for dynamic types (e.g. Point(x,y) can have numbers in JavaScript but I need a separate Point and FloatPoint for int/float in C++). This means I need to sometimes annotate the original Haxe-syntax code with hints about how it should translate into each language. For example, 1/2 produces a different value in Python (0.5) than in C (0), so I need to add hints to tell the transform code which one I mean.
I also translate the unit tests in this way, and run them as part of the output code.
It's been a fun project but it's grown out of hand. The past week I've been pondering refactoring parts of it.
The reason for all this complexity is that my original goal was to add a language drop-down on the implementation guide page. Then you could read the implementation guide in your choice of language, your choice of grid, your choice of indentation, etc. That was an overly ambitious project :-)