JSON parser grammar

David-Sarah Hopwood david-sarah at jacaranda.org
Wed Jun 3 20:49:58 PDT 2009

Mark S. Miller wrote:
> On Wed, Jun 3, 2009 at 7:47 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>> I am 100% in favour of tightly specifying what the ES5 JSON parser
>> must accept, and what it must generate -- subject to the following
>> caveat: [...]
>> The constructs that must be accepted but not generated are:
>>  - unescaped LineTerminators (at least <LS> and <PS>, possibly
>>   also <CR> and <LF>) in string literals.
> I thought the JSON grammar is already speced to treat <LS> and <PS> as
> whitespace, not newlines, and so could be included in string literals.

The problem is that many JSON parser implementations use eval, and
such implementations do not accept unescaped <LS> and <PS> in string
literals. That includes the reference implementation in the JSON RFC,
so the RFC is clearly in error (not self-consistent) on this point.

> (This has the unfortunate consequence that JSON is not a proper subset
> of ES5, but we've already reluctantly decided to live with that.)

I do not agree that we should live with it. The alternative of accepting
but not generating unescaped <LS> and <PS> is better.

> I see no reason why JSON should accept <CR> or <LF> in string literals.

This is less important; I don't really care about whether unquoted
<CR> and <LF> are accepted or not.

>>  - unquoted property names, matching <IdentifierName>, in
>>   object literals.
> Why? Had JSON been defined after ES5, no doubt it would have accepted
> these. But that's spilled milk under the bridge on which the train has
> already passed.

This has nothing to do with ES5. It is about the fact that there is a
*lot* of nonconformant pseudo-JSON out there that has unquoted property
names. Rejecting it will make the ES5 JSON parser significantly less useful
and less interoperable.

David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

More information about the es5-discuss mailing list