On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:
We can only focus on what's next. Our covenants the
s/the/that/
proscribe certain features are few: no ES4-style namespaces (Common
Lisp packages), nor packages built on them.
I reviewed the Harmony announcement message:
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html
The other proscribed feature was "early binding" in the sense of
static checking that made name binding and optional type annotation
judgments when compiling, and enforced them by failing compilation.
But this is either too vague or, if taken too literally, undesirable.
For Harmony we are looking at opt-in lexical scope, which would make
free variable uses into static errors:
http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope
As this wiki page says, the syntax is not crucial, but the idea of
removing the global object from the scope chain, of having only
lexical frames, is very much on the Harmony agenda. In such an opt-in
regime, early binding is possible and may be indistinguishable from
any binding.
The other kind of "early binding" ES4 did was of standard constructor
names in the global object when used as type annotations, by
implicitly opening the intrinsic namespace. This also early-bound
method names such as charAt on a statically typed string variable, or
a string literal.
This kind of early binding of names, creating an evaluation model that
is different from the usual one for names in expressions, is really
what the Harmony message meant to proscribe. TC39 agrees now to make
any optional type annotations evaluate dynamically (implementations
may partially evaluate as an optimization).
I admit it is hard to make precise statements that ban certain areas
of extension from ever being entertained by TC39, but I think that's a
good sign that we shouldn't close our minds excessively. The main
agreements were about getting controversial ES4 ideas, which were
already being removed from ES4 (packages went in April 2008), off the
table.
Again, there is no reason for us to "ban" decimal forever. That would
be wrong on several levels, most obviously because we would
standardize a popular decimal value type library if it emerged.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
