Live data from Hacker News

My experience crafting an interpreter with Rust (2021)

ceronman.com

21–30 of 53 posts

Re: My experience crafting an interpreter with Rust (2021)

#21

Does Crafting Interpreters require preexisting C knowledge? I'm curious to follow the book, but my experience with X is beginner level at best.

I've been teaching a class the lasts few weeks with a dozen people who have never programmed before using that book. It's going well.

Re: My experience crafting an interpreter with Rust (2021)

#22

Crafting interpreters is the best compiler/interpreter book I read. I had tried both the Dragon book and Andrew Appel's "Modern Compiler Implementation in Java" and Crafting Interpreters feels like a masterclass in how to write an accessible book. The author just has a special talent for explaining complex concepts simply.

I have a question about the book. I haven't been able to ask anyone else because I don't know anyone else who is working through the book. Is the first half of the book boring or is it just me? I wasn't really expecting the scanner/lexer to be interesting, but the interpreter part as well feels like an absolute slog. I started with a lot of enthusiasm but just couldn't keep going after implementing functions. I downl…

Compiler writing does involve a fair amount of tedium. I don't think it has anything to do with experience, either. It's why tools like Yacc, Lemon, or ANTLR exist.

Re: My experience crafting an interpreter with Rust (2021)

#23

Crafting interpreters is the best compiler/interpreter book I read. I had tried both the Dragon book and Andrew Appel's "Modern Compiler Implementation in Java" and Crafting Interpreters feels like a masterclass in how to write an accessible book. The author just has a special talent for explaining complex concepts simply.

I have a question about the book. I haven't been able to ask anyone else because I don't know anyone else who is working through the book. Is the first half of the book boring or is it just me? I wasn't really expecting the scanner/lexer to be interesting, but the interpreter part as well feels like an absolute slog. I started with a lot of enthusiasm but just couldn't keep going after implementing functions. I downl…

One tip, copilot is absurdly good at giving you interpreter/compiler boilerplate. You can definitely use it to speed through the boring parts.

Re: My experience crafting an interpreter with Rust (2021)

#24
> While the clox compiler does prevent a lot of these cases, it does not prevent stack overflows. The author intentionally decided to skip this check because it would require a lot of boilerplate code. Real-world interpreters using unsafe structures like these must absolutely do it though.

You can do both overflow and underflow checks without any efficiently loss by using virtual memory page faults to "catch" the resulting access (which in any case is a fatal error).

Re: My experience crafting an interpreter with Rust (2021)

#25
post #3
post #2

A downside of Rust for applications like virtual machines is that it doesn't have a goto statement. Ideally, both a labelled and a computed goto would be available in the language.

Not only does it not have computed goto (almost no languages do, tbh), it also doesn't have guaranteed tall-call elimination or allow you to use the GHC calling convention. Which are more egregious, imo.

> it also doesn't have guaranteed tall-call elimination

I had no idea about that. Is there a specific reason why that choice was made?

Re: My experience crafting an interpreter with Rust (2021)

#26

> I would often write huge refactorings thinking that they would be a solution to a borrow checker error, just to get another one at the end of the refactoring. Yeah this can often be a problem because the borrow checker doesn't kick in until the refactoring is done and no other errors are left.

Proficiency in Rust requires learning what won't work, rather than trying various things until they compile. Borrow checking is a set of rules to design for, rather than an oracle to test against.

It does take time and effort to really internalize these rules. But eventually you should be able to have a mental model of how ownership and borrowing work; consider what owns the data, if it can be borrowed within statically known scopes, will it need to mix sharing and mutation, and then apply Rust-specific types and design patterns to match.

Conversely, there are things that you just can't do, like using temporary references for parent-child relationships. Knowing this will save you time from even trying.

Perhaps learning materials need to be more explicit about it. For example, I suspect lots of people are discovering the limitation of self-referential structs the hard way.

Re: My experience crafting an interpreter with Rust (2021)

#27
post #3

Earlier quoted context omitted.

Not only does it not have computed goto (almost no languages do, tbh), it also doesn't have guaranteed tall-call elimination or allow you to use the GHC calling convention. Which are more egregious, imo.

I was looking for that (tail recursion) and it seems the story and feature request goes back years ago and still hasn't been added. Somewhere someone wrote that the issue is with LLVM but can't the tail call be transformed to an iteration before that?

The most practical uses of recursive functions are those that cannot be easily eliminated. For an interpreter, it could mean dozens of functions all calling each other in a pattern determined at runtime.

The issue used to be with LLVM, yes, but that appears to be solved (see Clang's 'musttail' attribute). Instead it's more about language design. Constructors, destructors, and all of the fancy language features Rust has must work with this new feature, with no changes being visible elsewhere.

Re: My experience crafting an interpreter with Rust (2021)

#28

Does Crafting Interpreters require preexisting C knowledge? I'm curious to follow the book, but my experience with X is beginner level at best.

I have the book but haven't gone through it. When I do eventually get to it, I will probably ignore all of the implementation languages, instead choosing something like F# or Racket. You could do something similar.

Re: My experience crafting an interpreter with Rust (2021)

#29
post #9

I’m curious about the extent to which DOS is a concern for an interpreter like this. I can see it be an issue if you’re exposing a service to external actors, but how big of a concern is it really in this context?

I'm going to assume that at least one popular interpreter uses a weak hash function for its hashtables/objects, and I haven't ever heard about it being an issue.

Re: My experience crafting an interpreter with Rust (2021)

#30

> While the clox compiler does prevent a lot of these cases, it does not prevent stack overflows. The author intentionally decided to skip this check because it would require a lot of boilerplate code. Real-world interpreters using unsafe structures like these must absolutely do it though. You can do both overflow and underflow checks without any efficiently loss by using virtual memory page faults to "catch" the res…

Only if under/overflow can be bounded. E.g., with stack probing.
Post reply on HN