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.
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.