Back to writing a Language target

Or… not.

It turns out that I dramatically overestimated the amount of documentation available for creating a new language target for Antlr4. Basically it boils down to "edit one of the existing targets" Except there are all sorts of template directives in there that aren't explained. I suspect the String Template documentation will probably address the syntax enough for me to understand the "what" of these templates but not the "why".

So, after staring at the Python language target file I tried just generating the syntax with it. Now I'm reverse engineering. I thought I'd start with the Ruby one since I'm so familiar with it, but in addition to not being supported it has a lot of files. Like… a lot of files:


I don't know if this is reasonable, or ridiculous. I'm inclined to go with "reasonable" because why would you write over 8,000 lines of code if you didn't have to?

So, now I'm wondering about maybe figuring out the grammar in Antlr using it's sweet plugin and visualization tools. Then, take the grammar, and reimplement it in Janet using its built in Parsing Expression Grammar (PEG). Every time I tweak the grammar, I do it in Antlr where I can visualize and tweak things until it works. Then re-implement the changes in Janet.

This is, of course, just a terrible idea.

However, my options are:

  • Spend a very long time reverse engineering how the eff to write an Antlr4 Language target

    • frustrating, time consuming, not even remotely fun
    • Probably will require writing thousands of lines of support code just to make it work, nevermind the code require to actually do the translation of the grammar into Janet.
  • Use one of the existing language targets (most likely Go)

    • So my compilation pipeline would be Tuplet -> Go -> Janet -> C -> executable This, of course, feels even stupider than reimplementing the grammar in Janet.
  • Port the grammar to Janet

I honestly can't decide which is a worse idea. Passing through Go, or porting the Grammar to Janet and then porting every new language feature too.

The Go solution has the option of being something I could get up an running quickly, that would likely give me a fast running executable that could be replaced in some future date. It's ridiculous, but it may be the fastest way to get to a working language. Also, it would likely prove to be a faster iteration cycle for new language features. I don't have to reimplement a working, and somewhat tested, grammar while potentially introducing bugs in a much harder to test environment.

I could write unit tests for the Janet PEG I'd write, so they could be reliable, but once again I'm introducing more time into iteration loop of going from some new syntax idea, to compileable Tuplet code.

I guess that's the answer. Most languages are bootstrapped off of some other language, because it'd take forever and be more painful to skip that. I guess the same idea applies here.

Sacrifice idealized compilation tool chain for speed of development. As i'm not really passionate about the compilation tool chain, that's probably the right solution.

[Update]: I spent the night dreaming about writing a PEG in Janet. 🤦‍♀️