Hacker News Reader

Comment by prestonbriggs | Hacker News Reader

I disagree. Forth is cute and you'll learn some stuff, but you won't become a compiler wizard. You _need_ to learn how to do parsers and run-time systems and all the rest.

Besides, it's fun!

View on HN

I see what you're saying, but respectfully I disagree. The importance of parsers and run-time systems in compilers really depends on the language you are compiling. There's a big spectrum there.

For runtime systems, on one hand you have languages where they are very important, such as runtime garbage collectors in Lisp, Java, and similar languages, Prolog's runtime logic backtracking, runtime exception support for C++ but no garbage collection, down to languages like C with no garbage collection and minimal runtime. Forth is certainly on the lower end of the compiler runtime implementation spectrum.

For parsing, there's a similar spectrum. There's languages with hideously complicated grammars, like C++, less complex ones like Lisp, and probably again on the simplest end of the spectrum is Forth.

So the requirement of needing to learn to write complex parsers and runtime systems is dependant on the language. I'd certainly classify a C compiler author as a "wizard" even though they wouldn't have to write a garbage collector for their C compiler, and a Lisp compiler author as a "wizard" even though their parser is much less difficult to create than a C++ language parser.

Of course, it's not like wizard is an exact term or anything. If you're saying a "compiler wizard" should be able to understand how to implement any language, then of course you need to have in-depth knowledge of parsers and run-time systems. Me personally, I'd say if you can write a compiler for any language you're somewhere on the compiler magician spectrum. Maybe not full wizard, but at least a compiler warlock or enchanter or something (this is getting silly now, I don't really want to argue about the semantics of the term wizard applied to compilers).

I'm far from a Forth wizard, but I've often heard it compared to a flexible assembly language for a stack machine. It seems like it could be the foundation for a visual programming language based on linking word blocks end-to-end, where you could zoom into user-defined words to get to the definition, etc. The simplicity of the language would/could prevent it degenerating into a tangled web of connections as when most languages are visualized.

Do you really need to cover everything in the first compiler you write from scratch or work on?

Nothing stops you from starting with a language that makes some aspects simpler then average (such as Forth or Scheme), before working on a compiler for a language that does require such things.

Or the succinct version, learn to walk before you run.

Of course not. But when you finish implementing Forth, you'll know how to implement forth, but not much else. But once you build a parser, you'll know how to build a parser for most any language. You don't have to learn every sort of parsing technique; I only use recursive descent. And once you learn for to do data-flow analysis, you'll find it applies whenever you want to write an optimizer. Same for various optimizations and code generation techniques.

Indeed, I'd argue that Forth is best appreciated after you've worked on other compilers for a while. Then you have a basis to appreciate how clever it is.

Reply on news.ycombinator.com