Have you ever wondered what it's like to create a new programming language? Were you put off by the parsing-theory focus found in most compiler-development books?

Well then, take a look at the "Crafting Interpreters" book, by Robert Nystrom (@munificent). Its online version is completely free (https://craftinginterpreters.com/contents.html), and covers everything from the basics up to bytecode generation, garbage collection and optimizations, in an easy-to-follow manner. Of course, if you find the material useful, consider supporting the author by buying a proper edition of the book (details at https://craftinginterpreters.com/).

#programming #programminglanguages #compilers #interpreters #langdev #computerprogramming #compsci #CraftingInterpreters
Table of Contents · Crafting Interpreters

First actual programming chapter of #CraftingInterpreters done. Had to do it over the course of several seasons but I’ve now got a working lexer: I can type in some code and the program will recognise it as code. Baby steps! Actually doing anything with the code is several chapters away.

An interesting thing is that I can already see ways I could do things differently. (Store the content of comments. Treat ints and floats separately. And so on.) Don’t want to get sidetracked by implementing that yet but looking ahead to how I might implement a language of my own.

My current thinking is to do the first half in both Java and Go, but chapter by chapter. Hopefully that way I can avoid getting sidetracked by any Go-specific problems. #CraftingInterpreters

first time writing actual java in ... 16+ years?

this is quite longwinded isn't it. not sure how much i want to deviate from the book — using type inference where the book writes explicit types should be fine, i assume?

or maybe i'll just go wild and try implementing it in go instead

#CraftingInterpreters

What strikes me is how well these C patterns are abstracted in safe Rust (aside from computed goto). For example, if I use equal-length instructions like in the Lua VM, then my instruction pointer becomes an `&[Instruction]` and I can fully(!) decode with `match chunk_rest.split_off_first()? {`.
Big thanks to @munificent — Crafting Interpreters inspired me to build my own programming language, Piscript (pixel Script)! 🚀
Just published it on GitHub: https://github.com/rolandbrake/piscript
#programming #interpreters #langdev #CraftingInterpreters
(Yet Another) implementation of the Lox scripting language from the book Crafting Interpreters (★★★★★).
It's not complete, but can run a range of interesting programs.
Hope it's useful to anyone else trying to translate the book into #zig
https://github.com/ringtailsoftware/zlox #craftinginterpreters
GitHub - ringtailsoftware/zlox: Zig implementation of Lox scripting language from Crafting Interpreters

Zig implementation of Lox scripting language from Crafting Interpreters - ringtailsoftware/zlox

GitHub

I'm a proud owner of a physical copy of @munificent's #CraftingInterpreters book, but today I learned about the web version. This should make coding along as I read a lot easier, and it has all the same charming bits as the physical book.

Thanks for a fantastic book in multiple great formats!

#PLdev

Picked up this book; it came highly recommended 😄
#CraftingInterpreters

@studiop It sounds like you're trying to represent the associativity and precedence of the syntax of these expressions as you build on them. I think the appropriate way to model this is as a tree.

From "Crafting Interpreters" [1] :

"One way to visualize that precedence is using a tree. Leaf nodes are numbers, and interior nodes are operators with branches for each of their operands."

[1] https://craftinginterpreters.com/representing-code.html

#CraftingInterpreters

Representing Code · Crafting Interpreters