Would there happen to be a PDF or eBook format of this?
PDF: http://compilers.iecc.com/crenshaw/tutorfinal.pdf At the bottom of the page.
Let’s Build a Compiler (1995)
31–40 of 58 posts
Re: Let’s Build a Compiler (1995)
#32Email me if you'd like an HTML version of this. I have converted most of it for my own personal use (through part 11, IIRC) but don't want to distribute it publicly since I'm unclear on the copyright status.
Re: Let’s Build a Compiler (1995)
#33This series is one of the best introductions to compiler construction. It doesn't cover everything and it's 25 years old now, but it is the only guide I know of that will hold your hand as you build a working compiler from scratch. If you have never built a compiler before, I cannot think of a better place to start. Afterward, if you're curious about theory and advanced topics, I recommend heading to Compilers: Princ…
A port of it to Python would probably be a better place to start. Not many people are conversant in Pascal these days.
Re: Let’s Build a Compiler (1995)
#34I audited Might's "Compilers" this spring. He live-coded a parser that parsed with derivatives, returning all possible parse trees whenever there were ambiguities in the grammar. [1] (Try getting that from yacc, or basically any other tool in existence right now.)
All of his coding was done in Racket scheme. At the beginning he told us we could use whatever for the projects, but doing certain things in C++ / Java / Python / some imperative language was "like bringing a knife to a gun-fight."
The final project was a working Python -> C translator.
Really badass class.
[0] http://matt.might.net/teaching/compilers/spring-2013/
[1] http://matt.might.net/articles/parsing-with-derivatives/
Re: Let’s Build a Compiler (1995)
#35Re: Let’s Build a Compiler (1995)
#36Reading the text files, using vim, which were written in the 80s and talk about Borland and other old stuff, makes me... a bit sentimental.
Reading that reminded me why I'll never make predictions on computing, especially on what can't be done.
Re: Let’s Build a Compiler (1995)
#37Lisp in Small Pieces is also a useful book, for those interested in Lisp/Scheme. It covers much of the same stuff as in the PDF I mentioned.
Re: Let’s Build a Compiler (1995)
#38This is definitely the classic online text. However, I'm surprised no one mentioned An Incremental Approach to Compiler Construction ( http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf ). It is the basis of the Ikarus Scheme compiler. Lisp in Small Pieces is also a useful book, for those interested in Lisp/Scheme. It covers much of the same stuff as in the PDF I mentioned.
Re: Let’s Build a Compiler (1995)
#39Email me if you'd like an HTML version of this. I have converted most of it for my own personal use (through part 11, IIRC) but don't want to distribute it publicly since I'm unclear on the copyright status.
Isn't contacting the author the natural thing to do? Some googling found a user profile for him: http://www.embedded.com/user/JackCrens
Re: Let’s Build a Compiler (1995)
#40If you're looking for a modern compilers class -- including the theory of why this stuff works -- I highly recommend Matt Might's [0]. All of the notes, slides, and code are online. I audited Might's "Compilers" this spring. He live-coded a parser that parsed with derivatives, returning all possible parse trees whenever there were ambiguities in the grammar. [1] (Try getting that from yacc, or basically any other too…
Any GLR-based tool can do that trivially, including recent versions of Bison (derived from yacc): http://www.gnu.org/software/bison/manual/html_node/GLR-Parse...
Ultimately I don't think this is the best way to develop parsers, particularly when you are designing the language itself (as opposed to writing a grammar for an existing language), because it gives you no hint that ambiguity exists until you actually encounter an ambiguous string (since the question of whether a grammar is ambiguous is undecidable).
I wrote more about this on my blog: http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why...