So apparently there's no such thing as LHS and RHS lookups in compilation, and it's a made-up concept to make the point that expressions are split, different assignments are made and errors can be different.
I find it a bit demoralising to spend several hours reading and learning all this stuff, testing myself in what is LHS or RHS only to find it's based on anecdote, which is what I thought we wanted to avoid. There's so much to learn as it is, why make up stuff and get us to learn it.
Fine if you want to give them as a helpful tip the help people think differently, but to go into such detail and keep repeating it as fact is a bit misleading.
Just a point... I am still very grateful for this excellent series, looking forward to reading through the rest! :)
there's no such thing as LHS and RHS lookups in compilation
I don't know where you're getting that information, but I have written compilers myself and there absolutely is a notion of tracking LHS and RHS, sometimes referred to as lvalue and rvalue. I stand by this assertion. It's not an anecdote. It's a concept. It's standard in basic compiler theory.
We were not, in this book or in my teachings, going through the source code of the JS engine and detailing exact implementation details. For one, different engines do things differently. For another, a single engine changes over time. And yet another, the actual architecture of the compilation/execution flow in a modern engine is much more complex than we can cover, including multiple layers of interpretation, JIT, optimizing, etc.
So, no, the words LHS and RHS may not literally appear in the source code of V8. But I am absolutely certain that the parser does track and understand if a variable is used in an assignment context (LHS, lvalue, etc) or in a value-lookup context (RHS, rvalue, etc).
As for the scope chain lookup during runtime... that I do later explain is a concept/metaphor, not a literal thing. One of the nice things about lexical scope is that (unless you use eval or with to "cheat") it's fixed at compilation time, meaning there's no need to look anything up because the location is already known.
If a naive engine were examined, one which did no optimizations, you would absolutely model scope resolution as a lookup. So, again, I stand by this as an explanation of concepts.
Hi Kyle!
That's great feedback, thanks very much. Happy to get clarity on LHS/RHS concept. Apologies for an unfair challenge! I guess it's important to be able to trust what you're reading.
I think I was just searching for reviews and also looked for more info on LHS/RHS and couldn't find much, and that lead me to http://stackoverflow.com/a/36385207/662826
I should know better than to naively trust a SO response, so thanks for clearing that up! :)
It's a great series so far, the depth of explanation is just right. It's good someone has taken the time to take things back to the computer science levels, without being pompous or overly complicated.
Most helpful comment
I don't know where you're getting that information, but I have written compilers myself and there absolutely is a notion of tracking LHS and RHS, sometimes referred to as lvalue and rvalue. I stand by this assertion. It's not an anecdote. It's a concept. It's standard in basic compiler theory.
We were not, in this book or in my teachings, going through the source code of the JS engine and detailing exact implementation details. For one, different engines do things differently. For another, a single engine changes over time. And yet another, the actual architecture of the compilation/execution flow in a modern engine is much more complex than we can cover, including multiple layers of interpretation, JIT, optimizing, etc.
So, no, the words LHS and RHS may not literally appear in the source code of V8. But I am absolutely certain that the parser does track and understand if a variable is used in an assignment context (LHS, lvalue, etc) or in a value-lookup context (RHS, rvalue, etc).
As for the scope chain lookup during runtime... that I do later explain is a concept/metaphor, not a literal thing. One of the nice things about lexical scope is that (unless you use
evalorwithto "cheat") it's fixed at compilation time, meaning there's no need to look anything up because the location is already known.If a naive engine were examined, one which did no optimizations, you would absolutely model scope resolution as a lookup. So, again, I stand by this as an explanation of concepts.