"Crafting Interpreters" - early-release version of textbook

[Schol-R-LEA]

Crafting Interpreters is a book on developing programming language translators - focusing on interpreters, but also covering compilers - which is being written by one Bob Nystrom. Nystrom has been releasing the early drafts of the chapters on this web site as they are written, hoping to get feedback and error checking from the community. Those here who have an interest in language translators might want to go over it.

[iansjack]

Looks interesting. Thanks for the link.

[dseller]

Thanks for sharing! Could probably learn a trick or two for my own project.

[Antti]

I read the first chapter and liked his writing style so far. Thanks for the link.

[klange]

Coincidentally, I started reading this a few days before Schol-R-LEA posted it here... I've forgotten so much from my uni compiler courses, but I want to get something cooked up to ship with my OS so the second half on building a byecode-based interpreter in C really intrigues me.

[thomtl]

Could this be handy for creating an AML interpreter?

[Schol-R-LEA]

Could this be handy for creating an AML interpreter?

The sections on lexical analysis, parsing, and general code-generation methods, almost certainly.

[alexfru]

Looks good and quite clear/clean.

[~]

The hardest part of a compiler is calculating expressions constructing instructions for the right precedence, variable/function types, intermediate results.

I'm thinking to develop a method of listing elements in a stack and depending on the precedence, pop them to calculate or keep them if the precedence still says to wait for calculating what I haev listed in the stack, in a single pass, just like when I read formulas to calculate.

I think that expression parsers actually do a single pass to the expression as it's read in, they don't need to complicate themselves with nesting of operations, just wait or go ahead to calculate according to the current precedence of the last operator, parenthesis...

[Schol-R-LEA]

The hardest part of a compiler is calculating expressions constructing instructions for the right precedence, variable/function types, intermediate results.

I'm thinking to develop a method of listing elements in a stack and depending on the precedence, pop them to calculate or keep them if the precedence still says to wait for calculating what I haev listed in the stack.

This comment tells me that you still haven't read any existing textbooks or other literature on compiler design. Precedence is a solved problem, solved at a completely different level (with most of it done in the grammar and the parser for same) and in a vastly easier manner than what you are attempting.

IOW, you are reinventing a square wheel made from cardboard in an era when steel-belted radials are the norm.

READ THAT DAMN BOOK. NOW. STOP TRYING TO HALF-@$$ THIS! Even as a pre-release beta, that book is a million times better than what you are trying to accomplish with your 'stone knives and bear skins' approach.

I, and others such as Solar, have given you links to a small library of books and other information sources on several occasions, and yet you still persist in acting as if this is something no one has ever attempted before. This is shooting yourself in the head, never mind in the foot.

Do you even have a grammar for the source language (which I assume is C or - Eris help you - C++) to design your parser from? Because without one, you have a snowball's chance in hell of getting anywhere with your compiler project. It isn't as if grammars for most major languages aren't readily available, either - the grammar for C11, along with the publicly released C11 draft standard update from 2014, is free from the OpenStandards website, as is the entire suite of draft C++ standards from 1998 to 2017, and while they aren't the final standards they are at least usable for your purposes - so there's no reason not to apply one to your lexer and your parser.

[iansjack]

The hardest part of a compiler is calculating expressions constructing instructions for the right precedence, variable/function types, intermediate results.

In other words - the hardest part of a compiler is compiling the source language to the final instructions?

Can't argue with that.

[Solar]

The hardest part of a compiler...

This comment tells me that you still haven't read any existing textbooks or other literature on compiler design.

Which is twice as sad as the website / book we're talking about in this thread is an excellent, hands-on (instead of theoretical) introduction to the subject...

Crafting Interpreters, by Bob Nystrom of Game Programming Patterns fame. Do give it a try.

The first part does it all in Java / tree-walk interpreter, the second part in C / bytecode VM. If I find the time, I'd like to re-do the second part in C++... but several other projects rank a bit higher at the moment.