New Feature to JS 1.7

[Garrett Smith]

On 10/8/07, Brendan Eich <brendan at mozilla.org> wrote:
> On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:
>
> >> I personally believe that the unsound, untestable/non-executable ES3
> >> spec is a rathole we should avoid. The errata (which are not complete
> >> by a long shot) that we have hosted at http://www.mozilla.org/js/
> >> language/E262-3-errata.html would have to be incorporated, again with
> >> high risk of bugs and no way to test. I think we are much better off
> >> working on the ES4 refimpl and the spec derived in part from it.
> >>
> > That is disappointing to hear.
>
> Why? Which particular word in "unsound", "untestable" and "rathole"
> was wrong, so that you'd be disappointed we didn't charge down that
> tunnel?
>
> > I sent an email to helpdesk at ecma.ch, as it is listed on the front of
> > the manual, but did not get a reply.
>
> That mail made it to my attention. The problem besides the lack of
> soundness and testability is that editing minor corrections can be
> done, but creates a difference between the Ecma spec and the ISO
> version of it. Editing non-trivial fixes is not well-supported by
> Ecma process or JTC-1 Fast-track to ISO.
>
> The fix is to do a new Edition, but that's not going to happen just
> to fix a few (or even a lot of) errata. It has been over eight years
> since Edition 3, and the JS authors deserve better than a typo fix or
> three.
True.

Our work on Edition 4 is all but specified. Meaning, we're
> about ten months from really all but done with the spec -- spec-
> writing is hard work, but at least this time there will be a testable
> reference implementation provided along with the spec, and bug-fixed
> over time.
>
> Modern standards are not holy writ, and as you note not bug-free.
> They should move toward continual refinement and release, as software
> has (Windows Update, Apple Software Update, etc.).
That is why IE is so far behind -- they dump a browser every 3 years,
then process bug rept's for the next 2 years, gathering information
for the next iteration.

It's also why the other browsers are advancing faster. Shorter release
cycles, public bug tracking, and Software update.

The Ecma process
> is not nearly that continual. The Scheme community wants to move
> toward a more frequent update of their spec (R6RS, R6.1RS, etc.). I'm
> working with Ecma folks to explore a way forward along those lines,
> but it won't happen quickly. The best plan now is to get back to an
> every-two-years release footing, based on ES4.
>
Shorter release cycles help to continually improve quality.

> > If the documentation were amended, understanding would most likely
> > improve.
>
> Maybe, but there're lots of JS books on shelves and people cope
> without delving into the corners of the spec that contain errata. We
> get very few complaints -- yours is one of a few cases where someone
> bothered to mail Ecma.
>
But it's not just books! Browser QA should be able to ascertain if the
implementation is correct of not.

But since ES4 covers ES3, the manual will, too, and will correct
problems in ES3.

> > BTW, I'm having trouble viewing ecmascript.org now.
>
> Works for me at the moment.
>
It looks like the problems of the ES3 spec are being positively
addressed. Shorter release cycles and tests. One more thing that would
help immensely: Interlinked HTML Format for the official release.

Garrett

> /be
>
>
-- 
Programming is a collaborative art.