Let’s Build a Compiler (1995)
compilers.iecc.com
compilers.iecc.com
This series is a large part of how I got started in the compiler business; and today I help maintain probably the most used Pascal compiler, in Delphi.
If anyone is interested in actually following along, TP 5.5 is freely available, though you'll need DosBox or similar if you're not running a 32-bit install of Windows:
Or there's Free Pascal, which is cross platform and backwards compatible with Turbo Pascal: http://freepascal.org/
"A word about style and efficiency. As you will see, I tend to write programs in _VERY_ small, easily understood pieces. None of the procedures we'll be working with will be more than about 15-20 lines long. I'm a fervent devotee of the KISS (Keep It Simple, Sidney) school of software development. I try to never do something tricky or complex, when something simple will do. Inefficient? Perhaps, but you'll like the results. As Brian Kernighan has said, FIRST make it run, THEN make it run fast. If, later on, you want to go back and tighten up the code in one of our products, you'll be able to do so, since the code will be quite understandable. If you do so, however, I urge you to wait until the program is doing everything you want it to.
I also have a tendency to delay building a module until I discover that I need it. Trying to anticipate every possible future contingency can drive you crazy, and you'll generally guess wrong anyway. In this modern day of screen editors and fast compilers, I don't hesitate to change a module when I feel I need a more powerful one. Until then, I'll write only what I need."
Interesting how something from 1988 can still be applicable today, even if pascal is 'mostly dead' the principles are valid.
It would be neat if someone took this as a base and used it to implement - and document - a language that people are more familiar with today.
If not for Borland Pascal would have died out long ago, but even today a fairly large number of people still hold on to the modern incarnation of it.
In theory, it might be nice to do something along the lines of Ruby, Python or Javascript, but those languages are, I think, too far removed from the CPU opcodes to get the same effect. Meta-circular interpreters, like in Lisp etc., are cute and are good for explaining the fundamental semantics of the language, but there's still an awful lot of magic baked in, in the same way that a C compiler written in C can embed the meaning of '\n' as a '\n' literal constant in the source itself. Of course, that magic may be subverted, most famously in the trusting trust essay:
I have a feeling that most people with the will to read a tutorial on compilers, and actually make it through the first chapter, are smart enough and work hard enough to figure it out.
[1] In case anyone's interested: http://github.com/samsonjs/compiler instead of emitting assembly instructions it emits x86 machine code directly.
Haskell Edition: http://alephnullplex.appspot.com/blog/view/2010/01/12/lbach-...
Any other?
Have you tried the top of the blog link?: http://alephnullplex.appspot.com/blog
I had made several attempts at learning how recursive descent parser works, but with little success. Finally I stumbled on this amazing text...
All other resources try to scare you by telling how scientifically mind-blowing subject the compiler construction is... this text simply shows how easy it can be.
Note: This may be an obvious question, but compilers are so far out of my area of experience that I don't even know what questions to ask.