Parse harmony let declarations.

src/contexts.cc

Index: src/contexts.cc
diff --git a/src/contexts.cc b/src/contexts.cc
index 72a5ae4d6077fab4a067c57553f7348eeeb8bfa4..c0e724253f2767ed2a6bbbee436db3c99cd9f62a 100644
--- a/src/contexts.cc
+++ b/src/contexts.cc
@@ -180,6 +180,7 @@ Handle<Object> Context::Lookup(Handle<String> name,
         switch (mode) {
           case Variable::INTERNAL:  // Fall through.
           case Variable::VAR:
+          case Variable::LET:

[Lasse Reichstein, 2011/08/12 08:08:33]

Should let be grouped with dynamic? If it occurs inside a loop, and the scope
also contains a function expression, it's possible to capture multiple versions
of the same variable (similar to a catch-scope). I.e., it can't be assigned to a
single stack slot.

[Steven, 2011/08/16 09:05:32]

Can you elaborate why it should be grouped with dynamic?

If you mean your for-loop example:
var accessors = [];
for (var i = 0; i < 10; i++) {
  let x = i;
  accessors[i] = function() { return x; }
}
here x is a fresh variable for each iteration of the loop, i.e. the accessor
closures will point to different instances of it.

The semantics of
var accessors = [];
for (let i = 0; i < 10; i++) {
  accessors[i] = function() { return i; }
}
though is now quite fixed yet. There is a choice if i is fresh for each
iteration or not.

On 2011/08/12 08:08:33, Lasse Reichstein wrote:

[Lasse Reichstein, 2011/08/16 11:00:46]

I was just trying to understand the comment above. If a variable is assigned a
fixed context slot, there can only be one instance of the variable in the
context. That doesn't seem to match the behavior of let-inside-loop, since
multiple instances can be alive at the same time.

On the other hand, this code doesn't seem to care about that, just that we know
whether the variable is read-only or not, so it's probably fine.

I believe the current consensus about for(let x = ...; ...; ...)... is that it
declares an implicit block around the for where the let lives (but for(let x in
...) will use a new instance for each iteration).

[rossberg, 2011/08/16 11:23:15]

There hasn't been any decision on that yet. At the last meeting, there were
voices in both directions, and Brendon himself seemed rather undecided. So I
would suggest that we go for what we consider more sensible for now (which I'd
argue are rules that are coherent between different let forms).

[Steven, 2011/08/16 15:06:08]

The context slot for the variable is fixed, but the context isn't. At the moment
each iteration will have a separate block context for the loop body, each one
having its once instances of block local variables.

As for the semantics of freshness of iteration variables, I had the impression
that there is no consensus yet :) The specific semantics is not important yet
and I think (hope) the implementation doesn't differ that much.

On 2011/08/16 11:00:46, Lasse Reichstein wrote:

[Lasse Reichstein, 2011/08/17 10:57:04]

I was relying on BE's comment in
http://www.mail-archive.com/es-discuss@mozilla.org/msg08908.html
It sounded authoritative enough for me to assume it was the consensus., although
obviously, I couldn't know for sure.
(It is, however, the what I would prefer too :)

             *attributes = NONE;
             break;
           case Variable::CONST: