ECMAScript Edition 4 Reference Implementation

As Dave Herman just posted at Lambda-the-Ultimate, we ECMA members who have been working on the successor to the JavaScript standard have a new website, which now hosts the “milestone 0” release of the ES4 Reference Implementation, written in Standard ML of New Jersey.

As Dave notes, this is a “pre-release” in the Open Source, “release early and often” sense. We are not done yet, but the Reference Implementation passes over 90% of the ES3 tests that we host in I should note here that the Reference Implementation already handles a great deal of ES4 in addition to most of ES3, so for example the self-hosted built-in classes are mostly there.

We know of some bugs, and we welcome well-written reports of more to fix. If you observe something that might be a bug, but you aren’t ready to file a Trac ticket, feel free to ask for advice on the es4-discuss list.

Extravagant praise to Dave for setting up the site and working on all the details of hosting the source files and binaries. Also to Graydon for tremendous work creating and developing much of the SML code. SML has been a good choice for us, although the performance of our (intentionally not very optimized) reference code can be poky. However, Dave says he is working on a MLton port, which should give a nice performance boost (MLton is an optimizing whole-program SML compiler).

This is just the beginning. Our plan is to finish the Reference Implementation over the summer and then work on specification language to surround pretty-printed excerpts of the SML and self-hosted ES4 code. At the same time, Mozilla, Adobe, and anyone who wants to help will bring up the new language on Tamarin in the new Mercurial repository. I’ll have more to say about that in a bit.


7 Replies to “ECMAScript Edition 4 Reference Implementation”

  1. Thanks for the update. Great milestone. (And I’m glad to see Trac for the project management.) Is the SML implementation expected to be used for Mozilla? In addition to working on getting it fast, I assume the compiled result will be small?

  2. By the reference implementation being used, I was asking about the parser and analysis parts. I understand that Tamarin would be the back end in any case. And I know you’ve mentioned the self-hosted compiler, too. I’m just curious about the direction. But I guess I should just be patient. Thanks again for the update.

  3. Sorry to comment so much, but I’m wondering about the potential for type inference. Does all static typing require explicit typing?

  4. Tom: search for Hindley-Milner to learn more about type inference. JS2/ES4 does not have a static type system on which H-M inference works.
    People often use type inference to mean other kinds of inference (e.g., C# 3’s local inference), but we have to be backward compatible, so an unannotated var or parameter has type *.

  5. Thanks for the pointers and answers. I was meaning the fairly conservative C# 3 style. I hadn’t seen this in the spec, so I was wondering if I’d missed it and/or what the thoughts were. Thanks for the answer (even if my question was fairly off topic from your post).

  6. Brendan,
    I posted a comment on Ajaxian on ES4 to which you kindly responded. I wanted to clarify and get your response. My apologies if this is the wrong place.
    I work on a JS framework that aims at Enterprise Mashups. I’m trying to make it ‘feel’ like rails. And, I’ve had to jump through a lot of hoops with the current language to make that happen. I’m unfortunately familiar with trying to bend JS to work something like ruby.
    On ES4, I understand that the language provides new features that will help developers make ‘better’ code (simpler, more intuitive, maintainable, etc).
    But I

  7. Justin: the problem with “if I’m careful, it’s not a problem” is that you are not the only author on the project, or in the mashup. There’s no silver bullet (yet), but if some other code can (intentionally or not) replace your properties or add unexpected ones, the result could be a security hole.
    I have a question about how your time is spent: is it on DOM and other implementation differences, or core JS (ES3) differences? If DOM, are you using an Ajax library consistently, or rolling your own? Thanks,

Comments are closed.