Bzo Devlog #0 : Compiler Status and Programmer Feedback

A peek beyond the paywall:

The lack of constraints is arguably a major advantage of weakly and dynamically typed languages, and a significant factor in why they are often considered much better for prototyping than static languages, even if they have significant drawbacks later on in development.

However, if the approach described here of combining layered constraints and error messages pans out (assuming the math and theory is correct), it could offer a way of breaking out of this tradeoff completely, and creating static languages that are vastly better than any other existing language at every stage of development, including the prototyping stage.

---

Development Status

I’m currently in the process of rewriting the compiler, mostly from scratch. Granted, there’s likely to be some code and plenty of lessons salvaged from older compiler projects here and there.

No worries though, I’ve gotten enough experience building compilers from the past few years of this project that development is definitely going much faster this time around. I’ve been pretty busy with my day job the past week or two, but I’ve still managed to get the lexer done, and I’m moving onto starting the parser.

In previous attempts at building compilers, I’ve taken the approach of trying to build out the entire lexer, then the entire parser, then the entire typechecker, etc. This makes everything an absolute slog to get through. Not just that, but often there is a great deal that is learned when working a few passes downstream—if it turns out I can simplify the typechecker by tweaking part of the syntax, it’s easier to do that before thousands of lines of parser code have been written.

I should have basic expression parsing working pretty soon, and I want to translate that to x86_64 machine code not long after and run it as a JIT.

Exploration

Designing every detail of a project before actually writing the code is, contrary to intuition, playing on hard mode. You’ll never be able to factor in every detail before writing the code—doing so is just as hard as writing every detail of the code, so why not do the design and writing together?

In previous attempts at this language, I’ve gone to great lengths to design the syntax and plan complicated mechanisms, only to hit serious complexity walls in the implementation details. That isn’t to say a complete lack of plans is ideal—quite the contrary. Get the abstract, deeply inspired ideas down first. Then work out how they materialize as you go.

I have a great deal of ideas for this language. If even one of them pans out, this language is going to be a big deal. If all of them do… oh boy. However, I’m not going to declare that I know right now how every last detail will work. This project is pure R&D at this stage—as much research as development.

Errors or Feedback?

I’ve recently decided to try something seriously unique with the way that Bzo handles error messages. The inspiration fell out of deep, abstract theory, and I expect it will have profound implications in practice. The compiler will not so much have an error message system, but rather a more general feedback system. I’d like to go through my current thinking on this, and the broad, abstract plans behind it.