
Writing An Interpreter In Go (2016) - tambourine_man
https://interpreterbook.com/
======
stevekemp
I had a lot of fun with this book, after belatedly buying it. I've read a
couple of similar online-books in the past, but this was the first one I
worked my way through completely.

As a result I later had a lot of fun writing a simple compiler for a reverse-
polish calculator, to generate AMD64 assembly language
[https://github.com/skx/math-compiler/](https://github.com/skx/math-compiler/)
, wrote a simple BASIC intepreter
[https://github.com/skx/gobasic](https://github.com/skx/gobasic) , and put
together a couple of DSL-projects which followed a similar approach.

All in all I'd recommend reading it, and definitely working through the code.
Once you're done you can continue to experiment - adding support for regular
expressions, a standard-library, etc, etc.

My version of the language is here and contains a fair number of
improvements/additions. After covering the core in such detail it wasn't hard
to extend further, even if that was primarily for fun, rather than for a real
purpose:

[https://github.com/skx/monkey/](https://github.com/skx/monkey/)

------
alexgmcm
Can anyone recommend other books similar to this one?

Having done the Nand2Tetris course and started the Ray Tracer Challenge book I
find I really like these books that guide you through a pretty complex
project.

It helps you learn by doing while at the same time preventing you from falling
into bad practices or getting overwhelmed.

~~~
kod
[https://www.itu.dk/people/sestoft/plc/](https://www.itu.dk/people/sestoft/plc/)

Sestoft is a very clear writer, and F# is a better language than most for
writing interpreters or compilers.

~~~
Scramblejams
How is the quality of F# in that book? I've been itching to make the leap and
this seems like a good way to do that, but I'd feel more confident if I knew
that Sestoft's demonstration of the language set a good example.

~~~
kod
I've never done F# professionally so I can't speak to how idiomatic it is, but
it gets the job done from a learning point of view.

------
azhenley
Highly recommend this book. After reading it (and the compiler book by the
same author), I started my own compiler for Knox, a Go-like language. It has
been a fun project, but I made some bad decisions regarding the type checker
and how I store the AST, so I'm currently procrastinating fixing those. You
can check out the source here:

[https://github.com/AZHenley/knox/](https://github.com/AZHenley/knox/)

------
neomantra
This week's Go Time podcast featured the author. It was enjoyable (as are all
their podcasts). He also has a compiler book that is the sequel.

[https://changelog.com/gotime/107](https://changelog.com/gotime/107)

------
jotaen
There recently also was an entertaining podcast episode with Thorsten Ball on
SE Radio, in which he talks about compilers vs. interpreters and about his
book as well: [https://www.se-radio.net/2019/05/365-thorsten-ball-on-
buildi...](https://www.se-radio.net/2019/05/365-thorsten-ball-on-building-an-
interpreter/)

------
voidhorse
What timing. I just started implementing an interpreter in go this past
weekend. I’d been following Bob Nystrom’s
[https://www.craftinginterpreters.com](https://www.craftinginterpreters.com),
translating java into go as well as comparing my impl to the go package
scanner, parser etc.
([https://golang.org/pkg/go/](https://golang.org/pkg/go/)) It’ll be very
interesting to compare my own approaches with Thornsten Ball’s to see if my
use of idioms and intutions about certain things were on the right track.

------
lghh
I'm about 1/4 of the way through it. I enjoy it so far. My only criticism is
that I wish it had something in the way of exercises. It's a lot of copying
(typing) code and it explaining what the code is doing and the concepts behind
what you've written. That's a good approach, but I enjoy thinking through
things on my own a little as well then being told how the author would have
done it and why. Otherwise very good!

------
tiuPapa
Lol, ebooks should have regional pricing like games. Buying these books means
I will have to shell out 1/3rd of my total monthly income (student in a third-
world country). Makes me wonder if there is a market for a paid service that
can make copies of books available for a monthly rate (kind of like a paid
ebook library with region locking and special format that can only be read by
the app with a constant internet connection - Netflix for books if you will ).
But I guess it would be hard to do because its just texts and if there was
money in this, Amazon would have done it already.

~~~
Denzel
The author is very friendly and responsive. I'm sure he'll respond to your
concerns if you reach out to him.

~~~
tiuPapa
Ah, my comment was not particularly about this book. It was just a general
assessment of how pricing may be a barrier for useful and practical books to a
larger set of audience. And a little bit of thinking out loud if there was a
viable solution to it.

------
ojosilva
I find it interesting that the Monkey language, created solely for the
examples implemented in this book, looks strikingly similar to a simplified
EcmaScript (ES2015+ actually). Is ES/JS the best example of a parseable
language? Why not just shoot for a (subset) ES interpreter instead of a made
up language that does not resonate as much with the reader?

~~~
skybrian
Using a fantasy language lets you avoid anything that makes the implementation
complicated or tedious.

------
reubensutton
I worked through this soon after it came out and I enjoyed it a great deal

~~~
giancarlostoro
Have you read other books with similar goals? How does this compare? I've been
meaning to go through and write an interpreter / compiler but havent found
time / right resources, but this seems interesting cause I've grown to love Go
more lately, and how you get so much out of the box. I might just try it, but
I'm curious what someone else's experience might be who was in my shoes when
they read it.

~~~
reubensutton
I studied compiler design at university and the subject matter here was a lot
more approachable, but in that, it sacrifices a lot of the theory.

~~~
lghh
I agree that it doesn't dive deep into a lot. It also makes notes of things
you don't need to know while you're working through the book. That said, if
you just want a basic grasp of what is happening to your code when you run it,
this is a good place for that. I don't plan on writing a compiler outside of
this book, and I don't think this book directly serves doing that. What it
does serve is my curiosity in a compact way.

------
mindv0rtex
As someone who just recently started learning Rust, I'd love to see a book
like this that uses it as the implementation language instead.

------
TeeWEE
I'm curious about this chapter:

"Why not a parser generator"

Seemse like the way to go these days? Why write it yourselve if you can
generate it from EBNF notation?

~~~
misternugget
Author here. I'm going to be super shameless here and quote myself in that
chapter:

> [...] we are here to learn, we want to understand how parsers work. And it’s
> my opinion that the best way to do that is by getting our hands dirty and
> writing a parser ourselves. Also, I think it’s immense fun.

In other words: use a parser generator when you need a working parser, quick.
But if you want to learn how parsers work, what ASTs are, what "top-down
parsing" means, etc. then I recommend you write your own. It's not that hard
once the concept "clicked" and, again, it's a ton of fun :)

~~~
pizza234
> use a parser generator when you need a working parser, quick.

Not necessarily. Use it also when you need a more correct one :-)

The way the book presents the parsing subject leaves the impression that a
handcrafted parser is generally preferrable.

I have experience with a project that was based on that book, and there were
(and probably, are) a lot of bugs in the parsing code, that wouldn't have been
there if a parser generator was used.

I don't camp for using parser generator at all costs, however, presenting both
sides of the coin would allow readers to make a (more) informed choice.

~~~
misternugget
> I have experience with a project that was based on that book, and there were
> (and probably, are) a lot of bugs in the parsing code, that wouldn't have
> been there if a parser generator was used.

I think I need to a add a big "do. not. use. in. production!" disclaimer then
:) The parser we build in the book is, of course, not a battle-tested,
industrial-grade parser that can survive every fuzzer you throw at it. Far
from it, but that's fine, since that was never the goal. The goal was always
to learn.

So, yes, I agree. If you do need a production-ready, stable parser: use a
mature parser generator or, maybe, invest more time in getting good at writing
parsers than it takes to read and work through the ~100 pages I wrote on the
subject.

~~~
bigtunacan
Since you have written a book in the subject you obviously are much more of an
expert than I am. After reading your book what materials would you recommend
for someone wanting to reach the stage is bring able to implement their on
"production grade" parsers?

------
towndrunk
I really enjoyed this book. In fact, after reading through it I wrote some
code to tokenize TypeScript with TypeScript. It was a fun little project even
thought I didn't really go all the way with it.

------
workthrowaway
funny, i was listening to the go time podcast during my commute this morning
and they had the author on...

the author seems to suggest that one should start with an interpreter, then
move to a compiler. (read the interpreter book, then read the compiler
book...)

i think it really depends on what you are doing. in fact, python is a good
example. it compiles to bytecode that is interpreted. it has the both
compiling thing going on and then the whole VM thing. i believe java is
similar. what i am trying to say is that the line is very blurry nowadays.

~~~
jonathanstrange
I'm not an expert, just a hobby language designer, but it seems to me that the
advantage of starting with an interpreter first is that this allows you to
more easily design a language in which compile-time expressions have some
reasonable expressivity. Generally, an interpreter allows the designer to
experiment more with the semantics. Typical examples are evaluation of
expressions for constant definitions at compile time or having built-in access
and language support (e.g. syntactic sugar) to 3rd party libraries like
arbitrary precision arithmetic.

The disadvantage is that it can be a lot of work. From my experience, writing
a toy VM in Ada didn't seem much easier than writing a compiler in a toolkit
like LLVM. (But I've never done the latter.)

------
dang
A thread from 2017:
[https://news.ycombinator.com/item?id=13707000](https://news.ycombinator.com/item?id=13707000)

