Slashdot Mirror
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.")
instead of using floating point for representing decimal numbers, one can of coarse easily use fixed point... for currency computations, just store every value multiplied by 100 and use some fancy printing routine to put the decimal point at the right position.
and if you're afraid that you might mix up floating point and fixed point numbers, just define a special type for the fixed-point numbers, and define corresponding overloaded operators... oh wait
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Implementations are expected to provide a safe(r) parser than eval.
Nerd rage is the funniest rage.
When you have strict regulatory rules about how rounding must be done, and your numerical system can't even represent 0.2 exactly, then it is most certainly a concern. There are other solutions, such as using base-10 fixed point calculations rather than floating point, but having decimal floating point is certainly more convenient, and having a hardware implementation is much more efficient.
Is that how JSON took hold? By being easy to parse using eval?
No, it took hold because it's Javascript's native object notation. And, as you can imagine, if you have a string of code you use eval to convert it. There are several JSON parsers which do some validation before using eval to ensure that it contains only an object definition and no statements. It would be nice if that validation was standardized and built-in.
they could have just used XML instead
Developers have a choice between XML and JSON (XML is already well supported), but many developers choose JSON instead of XML. Among other things, a JSON structure is typically smaller than a comparable XML structure, and when it's decoded you don't need to use anything special to use it.
instead of inventing a new serialized object format.
They didn't really invent this so much as realize that the native object format can easily be used to transfer arrays and objects between languages. It's very easy to create an associative array in PHP, encode it and send it to Javascript, and end up with virtually the exact same data structure in Javascript. Working with an associative array in PHP (or Javascript) is obviously a lot easier than working with an XML structure. Virtually any language you would use on a server has support for associative arrays or generic objects, so it makes a lot of sense to pass those structures around in a way where you lose no meaning and each language natively supports it.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Until we get a slick gui editor for javascript+svg animation, no.
In other words, we need GNU Ecmas.
Even easier would be to base all the system on cents. After that it's extremely easy to convert that cents value into a dollar/cents string.
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".
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
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.
Maw! Fire up the karma burner!