Live data from Hacker News

Crafting Interpreters: Closures

craftinginterpreters.com

21–30 of 62 posts

Re: Crafting Interpreters: Closures

#21
post #3
post #2

This is one of my favorite books(-in-progress) to follow along with. If you've ever even had a passing curiosity in how interpreters work, I highly recommend checking it out from the beginning: http://craftinginterpreters.com/welcome.html The writing is charming and approachable, while still packed with an impressive amount of knowledge.

Any more gems like this you would recommend?

Check this free book:

Introduction to Compilers and Language Design by Douglas Thain

http://compilerbook.org/

Re: Crafting Interpreters: Closures

#22

Earlier quoted context omitted.

Another approach is to do the opposite - always store all local variables in the heap, and rely on scalar replacement of aggregates to put them back onto the stack where possible. This is what I do in my Ruby interpreter. That’s definitely not compatible with a single-pass though!

Very interesting! Have you written anything about your implementation? I'm always keen to learn new techniques. I don't have much back end optimization experience (yet).

Section 4.2 of http://lafo.ssw.uni-linz.ac.at/papers/2013_Onward_OneVMToRul... describes it.

> We ensure this by forcing an escape analysis ... of the array containing the values of local variables. This eliminates every access to the array and instead connects the read of the variable with the last write. ... After conversion to SSA form, guest-language local variables have no performance disadvantage compared to host language local variables.

Then if the closure escapes (stored into the heap or something), the escape analysis just naturally fails and the frame is stored on the heap again.

Re: Crafting Interpreters: Closures

#23
post #7
post #3

Earlier quoted context omitted.

Any more gems like this you would recommend?

“Compiler Construction” by Niklaus Wirth (2014) [pdf] https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/... Modern Compiler Implementation in Java, C and ML. https://www.cs.princeton.edu/~appel/modern/ From Nand to Tetris https://www.nand2tetris.org/

Niklaus Wirth's, "Algorithms + Data Structures = Programs", is also a great read for the last chapter, "Language Structures and Compilers", which is a nice succinct read. It provides a little more formalism than Crafting Interpreters and it's introduction of representing grammar as a syntax diagram was especially helpful for me to visually understand the challenges of having more than 1 token of lookahead in LL(k) parsers.

Re: Crafting Interpreters: Closures

#24
post #3
post #2

This is one of my favorite books(-in-progress) to follow along with. If you've ever even had a passing curiosity in how interpreters work, I highly recommend checking it out from the beginning: http://craftinginterpreters.com/welcome.html The writing is charming and approachable, while still packed with an impressive amount of knowledge.

Any more gems like this you would recommend?

A colleague of mine just starting writing an online book about making a operating system for RISC-V in Rust: http://web.eecs.utk.edu/~smarz1/osblog/

Re: Crafting Interpreters: Closures

#25
post #23
post #7

Earlier quoted context omitted.

“Compiler Construction” by Niklaus Wirth (2014) [pdf] https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/... Modern Compiler Implementation in Java, C and ML. https://www.cs.princeton.edu/~appel/modern/ From Nand to Tetris https://www.nand2tetris.org/

Niklaus Wirth's, "Algorithms + Data Structures = Programs", is also a great read for the last chapter, "Language Structures and Compilers", which is a nice succinct read. It provides a little more formalism than Crafting Interpreters and it's introduction of representing grammar as a syntax diagram was especially helpful for me to visually understand the challenges of having more than 1 token of lookahead in LL(k) pa…

Yes. I love this book. At a practical level, it's pretty (very) outdated. It talks about things like sorting when your data is stored on tape.

But it's just a beautiful, succinct book. If you get tired of how messy, fast-moving, and chaotic a lot of software development can be, it's a delightful respite. It cleanses and orders the mind.

Re: Crafting Interpreters: Closures

#26
post #23

Earlier quoted context omitted.

Niklaus Wirth's, "Algorithms + Data Structures = Programs", is also a great read for the last chapter, "Language Structures and Compilers", which is a nice succinct read. It provides a little more formalism than Crafting Interpreters and it's introduction of representing grammar as a syntax diagram was especially helpful for me to visually understand the challenges of having more than 1 token of lookahead in LL(k) pa…

Yes. I love this book. At a practical level, it's pretty (very) outdated. It talks about things like sorting when your data is stored on tape. But it's just a beautiful, succinct book. If you get tired of how messy, fast-moving, and chaotic a lot of software development can be, it's a delightful respite. It cleanses and orders the mind.

From what I have read about Wirth his way of thinking is the computer science equivalent of Bauhaus minimalism. Which oddly enough doesn't appeal to me in the design of everyday things all that much (I can definitely respect it though), but feels very fitting for computer science.

Re: Crafting Interpreters: Closures

#29
Tiny question about lox : does it support arrays ? I understand it might not be that interesting as a concept so its removed from the example language to keep it smaller, but I was wondering if I missed anything ? If not, how would those be declared or implemented ?

Re: Crafting Interpreters: Closures

#30

Author here! Happy to answer questions, accept criticism, etc. :)

Checked the table of content, didn't find continuations. Am I missing something or is this material too much outside of the intended scope?

It's perhaps also too different, but I'd be interested in ways of saving the state of program execution and restoring that state later. Different from continuations, but overlaps...

Post reply on HN