
Show HN: Crafting Interpreters – A handbook for making programming languages - munificent
http://www.craftinginterpreters.com/
======
trishume
A fantastic book covering similar things that you can read right now is
[https://pragprog.com/book/tpdsl/language-implementation-
patt...](https://pragprog.com/book/tpdsl/language-implementation-patterns).
It's the book that got me into interpreters and compilers, I highly recommend
it.

It's slightly less in depth than the roadmap of "Crafting Interpreters", but
again, it exists right now.

~~~
agumonkey
Ha yeah, Terence parr is a référence.

------
codebeaker
Seems to be a hot topic, a friend and colleague published this in December
2016 and I can __thoroughly __recommend it (Uses Go as an implementation
language):

\- [https://interpreterbook.com](https://interpreterbook.com)

~~~
bruth
I can recommend this book as well! It is easy to read and understand and the
choice of Go as the host language is also great.

I am in the process writing a semi-natural query language (boolean logic)
targeted at domain experts (in this case biomedical researchers) that compiles
to either database queries (e.g. SQL) or a function call for arbitrary logic.
The goal of the compiler bit is to abstract away where the data ultimately
lives (similar to GraphQL) or how it is structured.

------
mwcampbell
Looking forward to the chapters about the C interpreter. Meanwhile, it looks
like both interpreters are available to study now in the Git repo. [1]

[1]:
[https://github.com/munificent/craftinginterpreters](https://github.com/munificent/craftinginterpreters)

~~~
throwathrowaway
Nice project. What do all the

//> SomeName not-yet

in the code mean? Are they meant for some kind of automatic processing? Its a
bit hard to read with all of them there...

~~~
munificent
Sorry, yeah. Those are the markers that the build script uses to insert the
code snippets in the right place in each chapter.

I know it makes the code hard to read. I should probably slap together a
little script to strip them out.

------
msangi
I really enjoyed
[http://gameprogrammingpatterns.com/](http://gameprogrammingpatterns.com/) and
I've been looking forward for this book since I saw the link on munificent's
homepage

------
kovrik
Thank you so much for the book, please, continue!

I am currently working on Scheme R5RS implementation in Java. It is a hobby
project, but I'm really enjoying it. It is somewhat enlightening.

Look forward to reading the Optimization chapter: I couldn't find much useful
and practical info on that. I think it is quite easy to implement your
interpreter, but it is really difficult (at least for me) to make it fast.

Can anyone recommend any articles or books with common optimization tricks and
techniques?

~~~
ioddly
For making an efficient Scheme implementation: most everything written by R.
Kent Dybvig or his students. I'd start with his PHd thesis (Three
Implementation Models for Scheme, specifically the stack-based part).

[http://www.cs.indiana.edu/~dyb/](http://www.cs.indiana.edu/~dyb/)

(See also Lua's upvalues for a way to optimize closure variable access that's
a bit simpler than his display closures).

~~~
munificent
> See also Lua's upvalues for a way to optimize closure variable access

Yes! In fact, that's how the C version of the interpreter in my book
implements closures. It's pretty brilliant. <3 those Lua folks.

~~~
Flow
Will you cover anything about LuaJIT's "NaN-coding"?

Or perhaps do you have a link about how it works?

~~~
munificent
Yes, we'll do NaN-tagged values in the last chapter on optimization.

------
zitterbewegung
I've been reading [http://beautifulracket.com/](http://beautifulracket.com/)
and its a really good introduction on making interprets.

~~~
throwaway7645
Interesting! I like racket...just wish it was faster. Anybody know if there
will be a successor to "Realm of Racket"?

Edit: Now I remember it uses LGPL as the license. I understand the reasoning,
but I've always viewed the freedoms as giving the user freedom over the
implementer...kind of just trading power.

------
szabot
I clicked the link without looking at the poster, and by the end of the
"What’s the Catch?" paragraph I was thinking to myself that this really seems
like something written by The Munificent Bob. Then I read the first sentence
of the next paragraph :)

I really like your blog, I have read all of it, some posts even 2-3 times, and
not only because of the content, but your writing style. I will probably read
this book too ;)

Also, I think Magpie is awesome.

~~~
munificent
\o/

------
ftomassetti
One think I find lacking in books about building languages is a focus on tool.
I am working on one (available for 0$ on leanpub: "How to create pragmatic,
lightweight languages"
[https://leanpub.com/create_languages](https://leanpub.com/create_languages) )
with the intention to focus more on building editors and simulator.

If you are interested in the subject you could take a look to my blog
([https://tomassetti.me](https://tomassetti.me)) I write 1-2 posts per week on
building languages. Most of the time I talk about DSL.

------
jonathanstrange
This is awesome, since I'm currently working on my own (toy) language! Thanks
for making this public!

On a side note, to anyone interested in an overview of high-level language
features and what their implementation requires, I can wholeheartedly
recommend Michael Scott's _Programming Language Pragmatics_. It doesn't go
into implementation details, but tells you a lot about the historical choices
and implementation possibilities of (mostly) mainstream languages.

~~~
munificent
_Yes!_ PL Pragmatics was the first book on languages I read and I really
enjoyed it.

------
Philomath
That's so cool! Learning to make a programming language is in my life's todo
list, just as doing my own (super simple) operating system. Thank's for
contributing with a free book, I very much appreciate it. Does anybody know of
something similar but for operating systems?

~~~
iKlsR
Not quite but this is a good read.
[https://littleosbook.github.io/](https://littleosbook.github.io/)

~~~
Philomath
This is good! It will definitely do.

Thank you very much!

------
nickpeterson
This looks great, for some reason the idea of creating a language from scratch
and then using it in some professional capacity always seemed really cool to
me.

------
GavinMcG
Really looking forward to this!

A much less involved language-building tutorial that's available now is
Beautiful Racket.[0] Racket is a Scheme, but it's also specially outfitted to
be a language workbench.

~~~
GavinMcG
And _16 hours_ later: [0]
[http://beautifulracket.com](http://beautifulracket.com)

------
whistlerbrk
A little late to the party here, but I'll throw another tutorial that I
absolutely loved, buildyourownlisp.com which guides you to building 'lispy' in
C.

------
xrayspec
Racket is also a great environment for making languages. See, e.g.:

[http://beautifulracket.com](http://beautifulracket.com)

------
d0m
One question here for the more advanced compiler writers.. How do you go about
writing a "pre-lexer" for LISP like language where you want to expand sexpr?
I.e. Does the lexer even see `(...), or does it get pre-extracted to (quote
..)? And if so, how does the pre-extraction work exactly? Is it built using
regex..? That can be tricky.

~~~
kazinator
Lisp dialects usually have an input mechanism called a "reader". It scans the
character syntax and produces the equivalent object, combining lexical
analysis and parsing. Special notations like 'x denoting the same thing (quote
x) are easily handled here. When the reader sees a quote, it consumes it,
calls itself recursively to scan the expression which follows to get an object
O and then returns the object (quote O).

------
plttn
Just from reading the first few pages of the book, I'm already a fan.

However my one tiny complaint is that the sign-up box is on every page, and
even after I've signed up, it still has to be closed every page I go to.

~~~
munificent
Yeah, that is annoying. I think for my previous book, I used a little cookie
support in JS to hide it persistently after the first time you closed it.

I'll try to resurrect that for this one.

[https://github.com/munificent/craftinginterpreters/issues/11](https://github.com/munificent/craftinginterpreters/issues/11)

------
bogomipz
This looks great. Thanks for sharing. Looking forward to updates.

------
dman
Any pointers to intermediate representations for compilers?

------
jnbiche
Another great-looking book on making _dynamic_ languages. There's been some
good ones recently, and this one looks like another good one covering how to
make a basic, interpreted language.

Some of us have written 1 or 2 dynamic, interpreted languages, feel pretty
comfortable with those concepts, and are interested in transiting to more
advanced, static type systems and writing a good type checker.

Anyone up for writing such a high-quality book as this one on statically-typed
languages, ideally functional languages? The only decent books I've found on
the subject are 20-30 year-old textbooks. I'm watching "Write You a Haskell"
with interest (and have partially read it), even though I'm more into ML and
Scala than Haskell, but it's still pretty unfinished.

There's also the plzoo, which is a great resource but not a book.

Oh, and I definitely need to read Pierce's Types and Programming Languages
textbook, I've ordered it and need to sit down with it. I suspect it will be
very enlightening.

But a more approachable book on statically-typed languages in the same genre
as this one is (popular, less academic) would also be welcome.

~~~
inconclusive
> more advanced, static type systems

Are static type systems more advanced than dynamic type systems? This sounds
surprising, given how much more one can do with a dynamic type system.

~~~
evincarofautumn
Basically, yes. You can do more with a dynamic type system than a static type
system because you don’t need to (and actually, aren’t allowed to) _prove_
that your code is consistent. Advancements in static checking and inference
mean you can prove more things about your programs, so you don’t have to fall
back on dynamic types and data structures so much.

------
peetle
'Git ta werk. ;)

