Release 14 of the Epoch programming language is now live!

That brings us to the pertinent and slightly bothersome question: what will be worked on for Release 15?


There are a number of features I'm interested in improving and/or implementing, ranging from object lifetime semantics to parallelism functionality. Strictly speaking, any and all of these features could be done in the existing compiler/runtime framework in a relatively straightforward manner.

However, given the recent success of my aggressive push to destroy the Epoch VM, I'm rather in the mood to continue decreasing the amount of C++ code I have to support in the project going forward. The next obvious candidate for removal from the C++ pool is the compiler itself. I want to rewrite the compiler in Epoch and use that as the foundation for future feature work.

In other words, it's finally time to start working on self-hosting Epoch.


I'm pondering which direction to attack this from. On the one hand, I could start by writing a basic parser, parsing simple Epoch files, and then build out the back end and slowly re-add functionality. However, I've done multiple compiler rewrites in this fashion, and every time I do one, I lose fragments of functionality for a long time.

In the interests of avoiding this sort of regression, I'm seriously considering a new tactic. Instead of starting with a new compiler front-end, I'm thinking about starting with the back-end instead. The parser already interops with Epoch nicely (I use it for syntax highlighting in the Era IDE prototype) so I could potentially leave the parsing in C++ for a while and build a new code generation layer in Epoch.

Here's roughly how that would work:

• Replace the bytecode emitter with an Epoch program
  
• Replace the code generation layer with an IR traversal that shells out to an Epoch program which in turn uses the new bytecode emitter
  
• Replace the AST->IR conversion with Epoch code
  
• Replace the parser->AST generation layer with Epoch code
  
• Finally, replace the parser itself
  

The advantages to this are twofold. First and most importantly, I never lose any existing Epoch features. Second and almost as interesting, I can release at any time once one of these steps is finished. This gives me a perfect opportunity to ensure the language doesn't move backwards in terms of features, while simultaneously moving it forwards toward the eventual goal of self-hosting.

Another perk of this approach is that if I do decide to add language features to help make self-hosting more practical, I can do so during any phase with minimal disruption to whatever code currently exists. I can also progressively delete code from the C++ codebase as I finish various steps instead of having to retain two independent "forks" of development.


All in all, I think this approach makes the most sense, and I'm already excited about the possibilities.


Once Epoch is self-hosting, the next step is to start on development tools. Era will be an interesting project for sure, given that my goal is to more or less invent a new IDE paradigm in the process of creating it. It's tempting to work on a debugger and other facilities prior to self-hosting, but the advantage of waiting is that I can prove that the entire tool-chain is self-contained end to end, rather than a hideous Frankenstein blend of Epoch and C++ components.

In some ways, I feel like self-hosting and creating a decent IDE for Epoch are the last two steps to having a project that is ready for serious prime-time usage. There's an almost infinite amount of refinement and feature work that can go into any language, obviously, but a language that can compile itself and offers robust tools for creating new software is hard to argue with.

It'll be fun to see if the rest of the programming world decides this language is as fun as I think it is :-)