ECMAScript Version 5 Approved

systembug writes "After 10 years of waiting and some infighting, ECMAScript version 5 is finally out, approved by 19 of the 21 members of the ECMA Technical Committee 39. JSON is in; Intel and IBM dissented. IBM is obviously in disagreement with the decision against IEEE 754r, a floating point format for correct, but slow representation of decimal numbers, despite pleas by Yahoo's Douglas Crockford." (About 754r, Crockford says "It was rejected by ES4 and by ES3.1 — it was one of the few things that we could agree on. We all agreed that the IBM proposal should not go in.")

Comments

I can guess why IBM was pushing for IEEE 754r

[tjwhaynes]

The debate over floating point numbers in ECMAScript is interesting. IEEE 754 has plenty of pitfalls for the unwary but it has one big advantage - it is directly supported by the Intel-compatible hardware that 99+% of desktop users are running. Switching to the IEEE 754r in ECMA Script would have meant a speed hit to the language on the Intel platform until Intel supports it in hardware. This is an area where IBM already has a hardware implementation of IEEE 754r - its available on the POWER6 platform and I believe that the z-Series also has a hardware implementation. I suspect that IBM will continue to push for IEEE 754r in ECMAScript, I wonder whether Intel is considering adding IEEE 754r support to its processors in the future.

Disclaimer: I have no contact with the IBM ECMAScript folks.

Cheers,
Toby Haynes

Re:I can guess why IBM was pushing for IEEE 754r

[H0p313ss]

There's also the mobile realm, where I don't think IBM has even stepped foot in.

The IBM JVM is used in mobiles. Lenovo (part owned by IBM) has/had a cellphone division.

Re:I can guess why IBM was pushing for IEEE 754r

[roemcke]

So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.

Personally a see two problems with this:

First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large_num+small_num)+small_num == large_num != large_num+(small_num + small_num).

Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.

In my opinion, the right thing to do is to look at Scheme. Scheme has two numeric types, exact and inexact, and leaves it to the implementation to choose what internal representation to use (normally integer or some rational number for exact numbers, and floating point for inexact). If a function can can make an exact calculation with exact numbers as input, it returns an exact number, otherwise it returns an inexact number.
The important here is that when the programmer needs exact calculations (for instance monetary calculation with fractional parts), he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.

There is only one minor problem with the scheme-way, it doesn't discourage the use of inexact numbers when it is obvious that the programmer is a moron. An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.

Floating point representation

[XNormal]

The floating point representation issue could be resolved the same way it is handled in Python 3.1 by using the shortest decimal representation that is rounded to the exact same binary floating fraction.

With this solution 1.1 + 2.2 will show as 3.3 (it doesn't now) but it will not test as equal to 3.3. It's not as complete a solution as using IEEE 754r but it handles the most commonly reported problem - the display of floating point numbers.

See What's New In Python 3.1 and search for "shortest".

Still no O(1) data structure

[Tailhook]

Back when ECMAScript 4 was still alive there was a proposed Vector class that had the potential to provide O(1) access. This is very useful for many performance sensitive algorithms including coding, compression, encryption, imaging, signal processing and others. The proposal was bound up with Adobe's parameterized types (as in Vector<T>) and it all died together when ECMAScript 4 was tossed out. Parameterized types are NOT necessary to provide dense arrays with O(1) access. Today Javascript has no guaranteed O(1) mechanism, and version 5 fails to deal with this.

Folks involved with this need to consult with people that do more than manipulate the DOM. Formalizing JSON is great and all but I hadn't noticed any hesitation to use it without a standard... ActionScript has dense arrays for a reason and javascript should as well.

Re:Any other notable changes?

[Bill, Shooter of Bul]

Read the article, it provides some explanation of why things are the way they are.

Plus, what exactly are your other options? Doing the entire page in flash or active X?

Also, sort of makes perl 6's development look a lot better, doesn't it?

Re:Any other notable changes?

[TheCycoONE]

There are several other things, the most significant of which in my opinion is property descriptors:

eg. For any property (value/function) of an object you can specify whether it is: writable, enumerable, or configurable; allowing for read only properties, properties which do not pollute a for(val in obj) call, and properties which cannot be messed with by other programmers.

See: http://ejohn.org/blog/ecmascript-5-objects-and-properties/ for a better description.