Tuesday, October 23rd, 2007

ECMAScript 4 Language Overview Final Draft

Category: JavaScript

The final draft for the language overview of ECMAScript 4 has been released. This is not the spec itself, but the starter overview document.

The fourth edition of the ECMAScript language (ES4) represents a significant evolution of the third edition language (ES3), which Ecma approved as the standard ECMA-262 in 1999. ES4 is compatible with ES3 and adds important facilities for programming in the large (classes, interfaces, namespaces, packages, program units, optional type annotations, and optional static type checking and verification), evolutionary programming and scripting (structural types, duck typing, type definitions, and multimethods), data structure construction (parameterized types, getters and setters, and meta-level methods), control abstraction (proper tail calls, iterators, and generators), and introspection (type meta-objects and stack marks).

ES4 also upgrades ES3 in small ways by fixing bugs, improving support for regular expressions and Unicode, supplying richer libraries, and adding lightweight facilities like type-discriminating exception handlers, constant bindings, proper block scoping, destructuring binding and assignment, succinct function expressions and definitions, and array comprehensions.

We first present the goals of the ES4 working group (ECMA TC39-TG1) and discuss the key issue of compatibility between ES4 and programs written for ES3 before we describe ES4 in its entirety1. We omit tedious details. This document is not a tutorial; the reader should be familiar with ES3.

Here you read about the fun new features such as:

  • Generic functions: generic function intersect(s1: Rect, s2: Rect) {}
  • Let const: let const color = 0xFEFEFE
  • Namespaces: namespace ns3 = “www.ecma-international.org”
  • “like”: var v: like { x: int, y: int }
  • Packages: package org.ecmascript.experiment { internal var v; }
  • Program units: use unit URLParser “http://www.mycompany.com/lib/URLParser”
  • For in: for ( i in obj ) print(i)

This is just a taste. Excited or scared about ES4? :)

Posted by Dion Almaer at 12:01 am

4.5 rating from 51 votes


Comments feed TrackBack URI

the “like” operator is great, but don’t forget about “wrap” (pages 17 and 30). It’s the other half of “like”, allowing you to facade for an object which would never (on its own) pass a “like” test. Think of it as a “view” or a “runtime prototype wrapper” for an object. Truly awesome.

Comment by Alex Russell — October 23, 2007

Awesome. Have to get my ‘read on’.

…fwiw… it would be a nice blog post (or add’l Ajaxian post) to list the new features of ES4 and talk about them, how they could be used, etc. …I’d love to hear what some of the ‘JavaScript Gurus/Titans’ have to say and learn from it — namely more insights from Alex Russell on this, along with Douglas Crockford, John Resig, Dean Edwards, Sam Stephenson et al. Would be thought provoking…

Comment by Mark Holton — October 23, 2007

Wow, that’s a lot of new stuff to potentially wind up in future versions of JavaScript and ActionScript. While I’ve seen rumblings of Ruby in the browser in the HTML 5 mailing list, so far ECMAScript is the only option for the presentation layer of a web site. This is important stuff!

Lately I have been enjoying a read through “Programming in Lua.” With a relatively small set of constructs, it provides many of the “advanced” (read: functional language) features mentioned, like proper tail calls and even closures. I don’t know if we’ll have other languages in the browser, but it’s certainly interesting from an architectural stand-point.

Comment by Nathan Youngman — October 23, 2007

I don’t really understand why an iterator objects throws StopIteration when its done iterating. To use a try/catch feels like somebody forgot to implement the hasNext() method.

Comment by José Jeria — October 23, 2007

I guess excited, but it doesn’t matter, because it will not be in browsers before 2017

Comment by Mike — October 23, 2007

Opera will probably implement this early 2009.
Mozilla and AppKit will probably follow Opera that year.
Internet Explorer will probably implement CSS 2.0 the same year.

Comment by David — October 23, 2007

Probably : )

Comment by Mrrau — October 23, 2007

@David: Doubtful. Whatever CSS support you currently see in IE7 is pretty much the best it’s going to get for the next 5 years. Microsoft should do the world a favor and switch to Webkit or Gecko.

Comment by GMFlash — October 23, 2007

@Mark: Crockford: “JavaScript is currently going through a redesign that is again failing to consider the security of the language. The new language will be bigger and more complex, which will make it even harder to reason about its security. I hope that that redesign will be abandoned.”

Comment by Steve Clay — October 23, 2007

It’s Really Awesome, I can’t wait until 2009 to use them! I just “love” ES4!!!
Does anyone know if at least packages will be “pseudo compiled” ? I mean something like ActionScript bytecode bacause it should be really interesting to write “everything” using for example strict mode without performances problems during execution and at the same time We could offer more using less bandwidth even improving execution performances (I talked about that many months ago with MTASC deveolpers and I hope Tamarin will be “that” kind of plugin I talked about)

Comment by Andrea Giammarchi — October 23, 2007

@Steve: the new language, I hope, will be based on a standard language/interpreter … and I suppose this is better than 4 or more dangerous languages … (IE versions, Geko versions, Opera versions, WebKit versions … and every other).
I wonder why We should stop ES4 implementations, it’s simply a natural evolution that will be much better (and more standard) than 3rd one.
Don’t You agree? Do You prefere multiple “buggy bad performances” JS 1.X versions? Even OS are not so secure, so just stop them evolution until We’ll have a perfect one? :-)

Comment by Andrea Giammarchi — October 23, 2007

Andrea: I’m not aware of any major compatibility issues between browsers in the base language. The DOM is ofcourse another matter entirely, but that won’t be solved by switching to ES4.

Comment by Joeri — October 23, 2007

For some reason I have a rough time grasping ActionScript 3. I havent worked with it in months, but when I did, I really struggled. I haven’t looked at the ES4 documentation yet, but if it is a lot like AS3, I am in for a world of hurt … 15 years from now lol

Comment by EmEhRKay — October 23, 2007

@Nathan: Lua is a great language, and Programming in Lua is one of the best books around on any programming language. Every programmer should read it, just to be exposed to some interesting ideas about languages.

A lot of game developers use Lua as the scripting language for their games. The Lua runtime is very compact and fast, and easy to integrate with C code.

We’re not likely to see Lua in the browser any time soon, though…

Comment by Michael Geary — October 23, 2007

@Joeri / @EmEhRKay … please read entire draft, ES4 is not like ActionScript 3 (it’s more funny, imho) and DOM is a little part of that draft but it’s quite clear that HTMLElements should be implemented as classes (or native DOM types?) so even IE should be able to add your own prototype to each element (however it seems that We’ll not need prototype as present scripts need them; prototype is “a different thing” in ES4 but it’s available and compatible with ES3 way too)


I’m not aware of any major compatibility issues between browsers in the base language.

just think about let, yeld, [a,b] = [b,a], for each in and every other amazing stuff We have only in Geko and We can’t use/write in a cross browser way.
Just think about every library We know, each one has, for example, its own implementation of Array.prototype.forEach … just think about a “less typeless” code and its performances … and so on.

What I mean is that in my opinion there’s any relation between JS browser security problems (please don’t forget that JS isn’t used only with browsers) and natural program language (impressive) evolution like that.
If security should block sofware evolution so We should still use Win 95 and Sco … isn’t right? :-)

Comment by Andrea Giammarchi — October 23, 2007

It has getters, setters, and method_missing! I’m in.

class C {
function get x() { ... }
function set x(value) { ... }

class D {
meta function get(name) { ... }
meta function set(name, value) { ... }

Comment by Michael Geary — October 23, 2007

Michael You should consider that Geko just has get and set (notation 1, not second one for dynamic invoke/management) … that’s Why I think a language evolution is a good point to “re-start” with JavaScript (really too much old version in too many browsers).

Comment by Andrea Giammarchi — October 23, 2007

could have sworn ‘for in’ has been in there for years…

Comment by steve H — October 23, 2007

in ES4 You choose what is enumerable and what not, for in is not the same and for(i * i in obj) is not possible with browsers that doesn’t support JS 1.7 or greater :-)

Comment by Andrea Giammarchi — October 23, 2007

@José Jeria : if You have a type hint enviroment there’s any problem to manage a StopIteration exception …

… iterate …
… continue ….
… break execution …
finally {
… doStuff if You need them …

hasNext is a “magic” method You should implement by yourself using intrinsic or caching next result in your iterator.

The best things I can see is that quite everything is customizable, starting with operators (+, -, === … others)

Isn’t cool? As I said, I can’t wait 2009 to use ES4 …. please run! :D

Comment by Andrea Giammarchi — October 23, 2007

@Andrea Giammarchi: I still think that the following code would be cleaner

var it = Iterator(myObject);

while (it.hasNext()) {

Comment by José Jeria — October 24, 2007

I agree with You but as I said You can implement that by yourself using Iterator’ and its prototype :-)

Comment by Andrea Giammarchi — October 24, 2007

Yes, but that implementation itself would have the try/catch…

Comment by José Jeria — October 24, 2007

Ok but it will be nested without affecting external try catch, so I can’t see where is the problem …

Comment by Andrea Giammarchi — October 24, 2007

Not a real problem, I just think that it would be cleaner and simpler to have a hasNext() method…

Comment by José Jeria — October 24, 2007

@José Jeria: The use of StopIteration to handle iterations is a completely moot point because anything which implements iteration can be iterated through the for (… in …) { … } syntactic sugar anyways. You can’t get much cleaner than that.

Comment by Blair Mitchelmore — October 24, 2007

Can someone compare this to actionscript 3?

Comment by jo — October 24, 2007

On for-in evolution: ES4 not only extends Object.prototype.propertyIsEnumerable with an optional second argument, so you can say “obj.fun = …; obj.propertyIsEnumerable(‘fun’, false)” to make obj.fun DontEnum, it adds a Python-inspired/improved iteration protocol that lets any collection object customize how for-in and for-each-in handle that object. This protocol uses structural types, there is no Iterator interface. As in Python, it requires only a next method to be implemened by the iterator. StopIteration is hardly ever caught by hand, because for-in and friends (including the comprehension forms) handle it. The while loops shown above should be for-in loops and try/catch in the loop bodies goes away.

On Crockford , cited by @Steve: It’s ironic that Doug invoked reason (“harder to reason about”), since reason => logic => proof => type system, and the supposedly simpler, smaller dynamic core of JS1/ES3 lacks not only types in the language, but basic things like immutable name bindings. You can override Object or Array (hazards to JSON decoders), or blow away someone else’s properties. This is good in prototype objects for AOP, maybe (I’m to blame for it, but I don’t defend it). For global bindings it’s a fatal flaw when trying to reason about type soundness and security properties such as integrity. ES4 is bigger in many ways (it has been eight years since ES3) but it is actually easier to reason about ES4 code than ES3 code, not only for humans but (more important, because reasoning should be automated where it can be, and you shouldn’t trust human-only security audits) for type checkers and security analyzers.


Comment by Brendan Eich — October 24, 2007

I totally agree with Brendan too!

@jo … ActionScript 3 is closer to Java than ES4 and in a first comparasion it seems that the only similar thing is strict type notation (x:Point) and classes structure.
If I’m not wrong AS3 hasn’t lambda like functions
function(x:int, y:int):int x * y
it hasn’t get / set shortcuts and meta declarations and I never read about intrinsic or for each in and array assignment (for i* i in … if() or [a,b] = [b,a]).
It seems that ES4 take advantages of many different languages such Python, Java, AS3 or Neko and ES3 itself … it seems to be a powerful and wonderful language using both old and new style code.

Comment by Andrea Giammarchi — October 25, 2007

@Michael Geary: True, I don’t expect Lua in the browser, but it certainly would be welcome if ECMAScript was architected towards simplicity. More power with less features… that’s why I am enjoying the Lua architecture, and the evolution of it:

Comment by Nathan Youngman — October 26, 2007

Leave a comment

You must be logged in to post a comment.