JSON parser grammar
Allen.Wirfs-Brock at microsoft.com
Thu Jun 4 08:07:00 PDT 2009
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Christian Plesner Hansen
>(Sorry for the repeat, my first attempt bounced because I wasn't
>subscribed to es-discuss)
>> The V8 implementation is a pretty early implementation and I would
>> consider all of the issues raised here to be bugs in it.
>It is indeed an early implementation but the decision to use the
>source parser directly is deliberate. Because of the way json2.js
>works anyone currently using it would get our implementation in the
>future and I didn't want to change the behavior in subtle ways under
>It's unclear to me from reading this thread if any other browsers
>actually implement JSON correctly according to ES5. If none do, how
>sure are we that these changes won't break people's programs?
The IE8 implementation also started with json2.js as the model and evolved in response to ES5 developments prior to IE8 production release. There are a few variances between the currently shipping IE8 JSON implementation and the current ES5 spec. A couple of these are bugs in our implementation and others are the result of late churn in the E5 specification (some of which we contributed to based upon our IE8 experiences). Almost all the variances deal with
API edge cases and unusual situations (for example, a Number wrapper object returned from a stringify replacer function might be rendered as an object rather than a numeric literal). Almost all of the known issues have been found by our internal testing and analysis of the algorithms and haven't shown up in user problem reports. Regardless, we intend to evolve our implementation to strictly conform to the final ES5 spec. as quickly as we can.
In releasing the IE8 JSON support most of the problem reports we received weren't related to differences between the IE8 implementation and json2.js. We actually discovered that jason2.js was not as widely used as we thought. Most of the issues we received involved encoding/decoding differences between our implementation (and jason2.js) and other encoders that applications were using. We also encountered issues where people were using the jason2 API names but applying them to differing, home grown APIs encoders/decoders.
So far, I think the implementers that have been actively engaged with ES5 development within TC39 have been doing a pretty good job of collaborating to make sure that all our JSON implementations are highly compatible with each other and with the emerging standard. Please feel free to join in.
>As for octal literals I agree that they're not a good idea. However,
>adding new special cases to avoid them is a cure worse than the
>disease. It adds to the complexity of the language in an area that is
>already dangerously complex.
More information about the es-discuss