Why decimal?

Brendan Eich brendan at mozilla.com
Wed Jun 24 12:22:58 PDT 2009


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


More information about the es-discuss mailing list