Lambda the Ultimate

JS is being used for general purpose web app programming (see Google Gears and the WHAT-WG APIs in modern browsers, which include SQLite now!), and increasingly for crazy 2D and 3D graphics bit-banging. Also some browser-based crypto. These workloads are a rising tide.

/be

I was merely echoing you ("Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony")...

(It has been observed in the past that my humor, especially when I am in sarcastic mood, can be confusing, especially in written conversation.)

Packages and namespaces are not the module system that the Web needs. No one can unseat the <script> tag for things like URL addressing, sync vs. async loading, DOM presence, etc. That's outside the language. But in the language, in the CDATA content of each script tag, JS desperately needs an optional module scope, with some way outside the module to require what is provided by the inside code.

Namespaces and packages are not this, and namespaces also require some kind of implicit module- (script-)based prioritization or reservation system. Otherwise you can get foo::baz and bar::baz conflicts across script tags that open foo or bar and define baz, then use baz without the prefix. Clearly, the first script (using just foo) is not ambiguous, and it would like its name judgments to be invariant, even possibly early-bound at compile time.

But without a module scope of some kind, foo can't defend against bar. Which could mean that any foo::baz where foo is open and baz is defined must reserve baz in all subsequent namespaces. A similar problem exists with subclassing and namespaces.

Also, as I noted, down-to-earth browser implementors object to the third dimension of name lookup added by namespaces and the 'use namespace' pragma (first two are scope and prototype chains).

Anyway, I did miss your humor, but it's clear the "unsound for the Web" line can be misinterpreted, and I wanted to shed some light on this point. Namespaces faced real problems, which ActionScript 3 in Flash solves with some kind of hidden module prioritization scheme, I'm told. ES4 never had a proposal along these lines, although the program units idea came close.

One of my goals for Harmony is to solve the "module" problem that the core language should solve: how to defend various kinds of judgments against the ever-extended top-level. LtUers should be thinking PLT and TypedScheme about now... ;-)

/be

solve the "module" problem

Big sigh of relief here.

A wise person once said "When someone tries to buy a shovel from you, remember that they may really want a hole in the ground." The way I see it is that the ES4 folks really wanted some syntactic conveniences, but thought they needed new semantics to get there.

Well, I don't think that's accurate, nor the implication that the ES4 group suddenly realized that "hey, all we need is this hole in the ground". It's more like, "we wanted the shovel, but it turns out it weighs 500 lbs, so maybe a hole in the ground is good enough." The 'intrinsic' namespace, for example... we aren't going to get those benefits from just new syntax.

Don't get me wrong, (h|H)armony is a Good Thing. But we wanted more than just a hole in the ground.

I would like to point out that ES3.1, which really only appeared as a spec draft this year, has grown some meta-programming APIs under the Object constructor-as-namespace that expose or add semantics not available in past editions.

So it's not really true that "no new syntax" (which became, with Mark's help, "must parse in 3 of 4 top browsers") meant no semantic extensions.

It's true the extensions are mostly straightforward, but they are not different in kind from differently-modeled extensions in ES4. For example, the [[Flexible]] attribute is ES1-3's DontDelete, inverted and with restrictions on its state evolution; Object.seal is similar in effect to ES4-as-proposed's notion of fixtures. However, ES4 namespaces were a big semantic extension, but they're out now and this was key to Harmony.

Mark's links to his es4-discuss@mozilla.org posts are worth reading, but be sure to read all of the followups. The whole story is more than one that can be told by congratulating ES3.1 people (and me) exclusively. Lars Thomas Hansen of Adobe (originally of Opera when he started working in TC39) deserves a lot of credit too, and his name is on the ES4 overview document. Waldemar Horwat of Google, to whom I handed the keys to the JavaScript kingdom at Netscape in 1998, has been a big help to all of ES4, ES3.1, and Harmony.

The politics of Harmony are threatened when history is revised to put all the virtue on one side. None of us likes unnecessary complexity. The trick is finding the simplest solution that is not simplistic.

Still, Harmony will endure in my view. The polarization between "no new syntax, now or ever!" and "Next Big Language" has ended without precluding the language from evolving beyond its current syntax and visible semantics.

This means changes for all the players on the committee. Even Doug Crockford said something nice the other day about an ES4 proposal (rest parameters and the ... [spread] operator). That's a big change from 2007's "We reject ES4 in whole and in part". :-)

/be

Sorry, the list was renamed from es4-discuss to es-discuss, but the old archive directory was not symlinked. Hoping to get that fixed ASAP.

/be

Sorry again for the temporary outage.

/be