Repository for the book "Crafting Interpreters"

I had trouble implementing break statement. I already added the tokens and statements with zero parameters (maybe there should be some - probably some context). I don't know how you would check if break is within a loop. I thought maybe check the tokens, but that would be tedious. Also I don't know how you would break out of a loop which is visited as another statement. Thought about exceptions but I know that is not the right way. So maybe you can give me some hints for these. Maybe it would be useful to put them in a book too because currently a note in challenge only describes what break is.

In some layouts, the "margin grafiti" (as Knuth would call it) and the source file annotations overlap.

See the attached screenshot, where main.c\n add to top of file overlaps with "The code tests for one and two arguments, ..." in the margins on the right-hand-side.

This line in chapter 2.3 may need adjustment:

So go has a compiler, is an interpreter, and is also a compiler.

Also, I am by no means an expert on this field (that's why I am reading the book!), but is go really an interpreter, or is it the OS/CPU which actually interprets the go generated executable. Whereby the command, go run acts as a wrapper to compile, then start the interpretation which is done by the OS/CPU?

Anyway, thanks again for another great book!

@munificent Section https://www.craftinginterpreters.com/statements-and-state.html#assignment-syntax shows this block of code:

  private Expr assignment() {
    Expr expr = equality();

    if (match(EQUAL)) {
      Token equals = previous();
      Expr value = assignment();

      if (expr instanceof Expr.Variable) {
        Token name = ((Expr.Variable)expr).name;
        return new Expr.Assign(name, value);
      }

      error(equals, "Invalid assignment target."); 
    }

    return expr;
  }

However, my IDE warns that the "Result of 'error()' is not thrown", so I think it should say:

      . . .
      throw error(equals, "Invalid assignment target."); 
      . . .

What do you think?

P.S. This book is excellent! I'm enjoying reading it so far and it's shed a lot of light for me on how compilers and tools like ANTLR work. I wish you all the best with writing the rest.

Section 3.8.1, Closures, includes this code snippet to demonstrate passing around a function as an argument:

print identity(addPair)(1, 2); // Prints "3".

Can that be right? Aren't the parentheses misplaced? Shouldn't this be:

print identity(addPair(1, 2)); // Prints "3".

I open up a hoopyfroop book and read the introductory chapter. It says, "hey, we're going to make a couple languages in Java, and later, we will learn about the structures to do it in C. No problem; we'll take it slow". Then I get to the challenges, #1 is a 'look at the repo and notice all the little languages', #2 is 'go get a Java Environment set up, you can figure that out.', and then we get #3: 'oh, also set up a C environment because we might need that if you stay with the book for a dozen chapters, and you should write some link lists in it, with helper functions, and tests.'

Are you sure it's not a typo and should say: "3. As a challenge, implement your own version of Linux in C. "

Parenthesis are here to allow a user to specify how to parse something, once the grammar is parsed, there is no need for an AST node that represent the fact that the input file has to be parsed in a certain way.

So Expr.Grouping and the corresponding visits that does nothing can be removed.

The document is copyright 2015 but only has the first 4 chapters. The rest say "coming soon!" but that's obviously not true. Please do your readers a favor and include information about the actual status and progress of this book and when they can realistically expect to see the rest of it. As it is, reading this is a waste of time when so much of the document is missing. Also it's a waste of time to post issues about the content, which I had intended to do.

And with that, we now have a complete scanner for the entire Lox lexical grammar. Fire up the REPL and type in some valid and invalid code. Does it produce the tokens you expect? - End of Chapter 4.7

What is the supposed end state for this chapter? My examples appear to have tokens with memory addresses. Is that what we should have at this stage?

> "Hello World"
[email protected]
[email protected]
> Hello World
[email protected]
[email protected]
[email protected]
> 1.2 + 2.3
[email protected]
[email protected]
[email protected]
[email protected]
> 1 + 2
[email protected]
[email protected]
[email protected]
[email protected]

Thanks for reading!

Thank you for your amazing book :D

I have currently learned to write my interpreter following the book. But I don't know how to implement a module system like Python. I couldn't find any tutorials on the internet.

I appreciate it if you give me a couple of hints.

In Repl mode, It's always better to be interactive and show how easy and fun using a programming language can be. After trying current version of Lox, figured out you need to use print statement to figure out what is the result of an expression.

By expression I mean return value of function, Initial expression of variable and direct coding like 1 / 2 .

Issue current-version :

10 + 10 ; ..

In the last paragraph of section 24.3, the book reads: "Assuming we did all of that correctly, we got clox back to a runnable state. Fire it up and it does... exactly what it did before.".

This is not entirely true. In interpret, the initial function is pushed to the stack, and at this point it's only popped if a runtime error occurs. This means that successive invocations of the REPL without errors will have issues with locals, as the bytecode only expects there to be one value in the frame when the bytecode starts being executed.

The issue is fixed in 24.5.4 with the new code for OP_RETURN, which pops the value from the stack.

It might be worth changing the wording, since this can cause some confusion for readers that are following along, and want to test their code after section 24.3.

I'm working through the book, and I'm finding it a bit awkward to navigate back to the contents page. So I have added a link to contents from the floating navbars.

This looks fine when the navbar is stretched. However, on some pages, or when you scroll down, it squashes, which doesn't look as good. Maybe someone who knows the project better than me can improve on this?

   This looks fine, IMO.

   Scrolling down... not quite as nice?

   The final page also doesn't look quite right.

Section 24.5.3 has to do with printing stack traces. It ends with entering in a broken program to demonstrate the stack trace.

fun a() { b(); }
fun b() { c(); }
fun c() {
  c("too", "many");
}

a();

If you run the program from the REPL by creating each definition in turn then at this point in the chapter you will produce a segfault after you enter in the second function. (Really it works with any pair of statements you enter.) This is fixed in the next section (24.5.4) because we add in return values so all's well that ends well.

However, I would recommend adding a note next to the example that warns the user that they will get a SegFault from the REPL, but not from a file. (It could even include a cheeky author comment asking the reader to consider why this might be the case.)

I burned an hour trying to figure out why the vm.frameCount underflowed (That's C, baby!) and where I deviated from the book as written. Turns out everything was working as expected. I just needed to keep following the book.

Thanks for writing this lovely book and putting it online! Really appreciate it!

To reproduce:

make clox
./clox test/benchmark/string_equality.lox

Output:

[line 32] Error at 'a4': Too many constants in one chunk.
[line 32] Error at 'a7': Too many constants in one chunk.
[line 32] Error at 'a5': Too many constants in one chunk.
[line 32] Error at 'a7': Too many constants in one chunk.
[line 32] Error at 'a6': Too many constants in one chunk.
[line 32] Error at 'a7': Too many constants in one chunk.
[line 32] Error at 'a7': Too many constants in one chunk.
[line 32] Error at 'a7': Too many constants in one chunk.
[line 32] Error at 'a8': Too many constants in one chunk.
...

The same benchmark works correctly with jlox because it doesn't enforce limits on constants, but it would be great if the benchmark was updated to something that could run on both, so that they could be compared more easily.

The bold code fragment should be IS_EMPTY. Otherwise the key nil would not be possible in a hash table.

+bool tableGet(Table* table, Value key, Value* value) { if (table->entries == NULL) return false;

Entry* entry = findEntry(table->entries, table->capacity, key);

• if (entry->key == NULL) return false;

• if (IS_NIL(entry->key)) return false;

  *value = entry->value; return true;