Epoch in the near future
A lot of what still needs to be done for the R12 compiler rewrite involves simple AST transforms and semantic validation. This is the kind of code that's really beautiful and easy to write in a functional language, and slightly masochistic in C++. Since the Epoch compiler is currently a C++ affair exclusively, this translates into lots of gross imperative nonsense and boilerplate to do some fairly trivial manipulations of the code tree.
I can't count the number of times I've been working in C++ on some large project, and desperately wished for a language that let me think abstractly and still hammer down on performance as necessary. That was, in essence, one of the biggest motivations for doing Epoch in the first place - to enrich the kinds of abstraction I can think in, without sacrificing the ability to do it fast and in reasonable amounts of memory.
Ironically, Epoch itself has become yet another prime example of this phenomenon. I no longer relish working on the compiler (at least the kinds of stuff I have to do at this immediate moment) because it's bogged down in an endless mire of standard library containers, iterators, smart pointers, exception safety, pointlessly stupid abstraction limitations, and missing language features. So many times I sit down to work on some part of the compiler, and immediately some elegant solution involving decomposing pattern matching pops into my head, and I spend a few minutes swearing under my breath at C++ and its dilapidated lack of power before closing Visual Studio and going out for a drink to relieve the stress.
Clearly, not much progress is being made this way.
Thankfully, one of my original goals with writing the Epoch compiler this way was to escape C++ implementation as soon as the Epoch language is rich enough to allow it. In essence, I want to write Epoch's compiler in Epoch itself. This is great on a number of fronts. First, it proves that the language is robust enough for prime time. Second, and just as important for Epoch's priorities, it proves that the execution environment is fast enough to do something nontrivial like compile itself. Third, it reduces the mental effort needed to implement the whole shebang, because I can finally start thinking at a more natural level of abstraction than I can easily do in C++.
My recent frustration with the compiler project has led to a refreshing conclusion, of almost slap-myself-upside-the-head obviousness: the time to start moving away from C++ is now.
Well, not now really; I have to get the compiler working again first. That means finishing and releasing R12 so I can get that out of the way. But as soon as the R12 compiler implementation works, I can at long last get my head above the murky, briny water of C++ and breathe some real, fresh air.
My roadmap for the next several months of Epoch development looks vaguely like this:
- Finish semantic validation in the R12 compilation model
- Implement code generation in the R12 compilation model
- As a proof of readiness, build extended syntax highlighting into Era, using the new, faster parsing layer
- Ship R12
- Design and implement bindings between the R12 parser and the Epoch runtime
- Implement language features/data structures/library functionality such that Epoch programs can traverse Epoch code
- Port semantic validation into Epoch
- Port code generation into Epoch
- Remove the C++ back-end from the compiler entirely
- As a proof of readiness, compile the Epoch compiler in itself, as well as Era and the compiler test suite
- Ship R13
- Examine the feasibility of moving more and more of the Epoch implementation into Epoch and out of C++
- Reassess the situation and devise a plan for R14 and forward
I've spent many years longing for a language environment where I could easily build the kinds of software I'm interested in working on, and even extend my language and its development tools where they fall short. It looks like that future is finally beginning to dawn.