[Webkit-unassigned] [Bug 31813] Add support for block scope const

Thu Nov 17 04:06:00 PST 2011

https://bugs.webkit.org/show_bug.cgi?id=31813

--- Comment #8 from Andy Wingo <wingo at igalia.com>  2011-11-17 04:06:00 PST ---
Harmony (or ES.next or ES6, which are the same thing) is shaping up to
be a pretty big language.  There is consensus on some pieces, and some
pieces are more experimental.  From an implementor's perspective it is a
waste of time to implement something that will change significantly in
the future, so we need to identify a stable subset of Harmony to
consider implementing.

Given that we are looking at block-scoped const in the broader Harmony
context, I thought it would be useful to look at what V8 has identified
to be a stable subset, and what they are doing.

V8 implements (1) harmony proxies, (2) collections (maps, sets, and weak
maps), (3) typeof, and (4) block scoping (const and let).

In V8, all harmony support is currently off by default.  There are
separate runtime flags to enable each one of these four areas.  There is
a master --harmony switch to enable all of them.  Even when it is off,
Harmony support is always compiled into V8, without an #ifdef.

1. Proxies are implemented as a separate JSReceiver implementation,
JSObject being the other one.  There are about 100 mentions of JSProxy
in the V8 source -- so a fair amount of code, but not enormous.  Proxies
do have a couple of runtime helper stubs, but otherwise don't affect
code generation.  That's all I have to say on proxies.

2. Harmony collections (sets, maps, and weak maps) likewise don't affect
the core implementation too much, as they are essentially libraries.

3. In Harmony, typeof(null) is 'null', not 'object'.  This affects code
generation in some places, mostly positively.  I don't know how much it
would break the web if it were on by default, though.

4. OK, so we are finally down to scoping.  This is the most complicated
piece.  I have described the specification for block-scoped const in bug
31813 comment 2.  V8 implements it entirely, except for `const' at
toplevel.  `let' is very similar to `const', except that the bindings
are mutable.  There is still a "temporal dead zone".

I should mention first that like JSC, V8 has a legacy `const' mode.  It
does not reserve the `let' token in "classic" mode (see
comment 1).  In strict mode, it raises early errors for `const' and
`let'.  In harmony mode, it implements harmony scoping.

Crankshaft does not handle `let' or harmony `const' yet, so using these
constructs is currently a speed penalty relative to `var'.  Of course
the read barrier ("temporal dead zone") is also a performance lose, but
probably not too significant.  V8 does omit the read barrier in one
case; from full-codegen-ia32.cc:

 // The check
 // can be skipped in the following situation: we have a LET or CONST
 // binding in harmony mode, both the Variable and the VariableProxy have
 // the same declaration scope (i.e. they are both in global code, in the
 // same function or in the same eval code) and the VariableProxy is in
 // the source physically located after the initializer of the variable.
 //
 // We cannot skip any initialization checks for CONST in non-harmony
 // mode because const variables may be declared but never initialized:
 //   if (false) { const x; }; var y = x;
 //
 // The condition on the declaration scopes is a conservative check for
 // nested functions that access a binding and are called before the
 // binding is initialized:
 //   function() { f(); let x = 1; function f() { x = 2; } }
 //

Note that if you come from a functional programming backgroud, harmony
`let' is more like `letrec' (or `letrec*') from other languages, hence
the complications.  The general strategy from "Fixing Letrec: A Faithful
Yet Efficient Implementation of Scheme's Recursive Binding Construct",
by Oscar Waddell, Dipanwita Sarkar, and R. Kent Dybvig could apply here.

Anyway, sentinel values and read and (in the case of `const') write
barriers.  There's more though.

In harmony mode, every call to `eval' is a strict-mode eval call.  This
behavior is enabled by the harmony-scoping flag.

In harmony mode, you need to check for multiple declarations of the same
let-bound or const-bound variable.  You need to check for incompatible
bindings: `var' and `let' declarations in the same scope, or `var'
hoisted past a `let'.

In harmony mode, a SourceElement may be not only a Statement or a
FunctionDeclaration, but also a LetDeclaration or a ConstDeclaration.
ConstDeclarations have non-optional initializers.

Function declarations are scoped using `let' in harmony mode, and thus
are block-scoped, not hoisted.  For named function expressions, the
closure binding between the name and the function is made using `const',
in harmony mode.

In harmony mode, a Block is parsed as a sequence of SourceElements, not
Statements.

Catch vars are bound using `let' in harmony mode.

That's it, I think.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.