Typo: chapter 2.3 about craftinginterpreters HOT 8 CLOSED

but is go really an interpreter, or is it the OS/CPU which actually interprets the go generated executable.

My claim is that it is. :) You are correct that it "interprets" by compiling your Go code to machine code and then having the OS immediately execute it. But that's also what V8 and some other JIT VMs do, and we tend to call those "interpreters" as well.

From the user's perspective, the fact that go run compiles to machine code is an implementation detail. For example, if CPython started using PyPy internally instead of it's own bytecode compiler, from the user's perspective, nothing would have changed (well, except for it hopefully getting faster).

from craftinginterpreters.

Ah yes, I agree with you now!

Sorry, I may not have made it clear, but the line in chapter 2.3 is still a typo! Read below.

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

The repetition of, "has a compiler" and "is also a compiler".

from craftinginterpreters.

The repetition is weird, but deliberate. "Compiler" has two meanings:

• It describes the user experience of invoking the tool to turn your code into some other form, which you then must explicitly "run" in some other way.

• An internal process where code is translated to some other representation, but not in any user-visible way.

Python has the latter but not the former. GCC has the former, but not the latter. Go has both. go run is the former, and go build is the latter.

from craftinginterpreters.

After carefully rereading 2.3: Compilers and Interpreters again, I can finally discern that the sentence is very much deliberate! However, I believe the casual reader (me!) may not pick up on your subtle variations in the verbs you use: "to be" and "to have", which you use to distinguish these two definitions.

Also, wouldn't it be more sensible if a "Compiler" had a single meaning:

• Translating code into some other form or representation.

However this process can be user-visible (GCC), or not user-visible, instead internal (Python).

Regardless of your conclusion, throughout the chapter you tend to focus on the fact that implementations may be both an interpreter and a compiler, but you don't ever explicitly explain that "Compiler" has these two separate definitions (maybe it was implicit).

Anyway, I hope I am not being a pain! These details are fairly minor and you are the expert! Perhaps you should get feedback from another reader, as it may well just be me ridiculous! 😁

from craftinginterpreters.

Good point! I'll reopen this and try to clarify the text.

Also, wouldn't it be more sensible if a "Compiler" had a single meaning:

It would be. Alas, we don't get to rewrite everyone's brain, and I'm describing how people use those terms today, not how I wish they did. :)

People do say that "GCC is a compiler" and "Python has a compiler" (but rarely that "Python is a compiler"). I'm just trying to explain what they mean when they say that.

from craftinginterpreters.

Yep, I see what you mean now. As long as you explicitly explain the difference everyone will be fine!

Thanks for clarifying!

👍

from craftinginterpreters.

I also stumbled over this bit, and after pondering for a second understood what you meant—or assumed that I did, and your clarifications confirmed that. I already know Go and a bit about compilers, though, so I might not be the absolute beginner who is confused by that statement.

I do like the phrasing, but think it is a bit unfortunate, mostly because if the reader knows the book is a work in progress they might think this part is not edited yet and just dismiss the statement, which would be a bummer.

from craftinginterpreters.

👍

from craftinginterpreters.