JSON parser grammar
david-sarah at jacaranda.org
Thu Jun 4 16:38:40 PDT 2009
Mark S. Miller wrote:
> On Thu, Jun 4, 2009 at 8:07 AM, Allen Wirfs-Brock
> <Allen.Wirfs-Brock at microsoft.com> wrote:
>> [...] Not supporting JSON octal literals adds no complexity to
>> the ES5 JSON spec. because they are simply not part of the
>> format and are never mentioned. It only adds complexity to
>> lexer (assuming it supports octal constants) to lex JSON text
>> and there are already enough other differences between the JSON
>> and ECMAScript token set that it isn't clear that this is a
>> good idea. Regardless, ES5 lexers are already required to not
>> recognize octal number when operating in strict mode.
> No, it does add some complexity to the spec differently from the sense
> in which octal is prohibited in ES5/strict. In ES5/strict code, the
> literal 010 must be interpreted at a decimal 10.
This is mistaken; 010 is a syntax error (modulo section 16 extensions)
in both strict and non-strict modes:
> In JSON.parse, 010
> must be rejected. In order to mandate this, the standard JSON grammar
> (as documented both in the RFC and on json.org) does not allow any
> digits after a leading zero. I support this added complexity for all
> the reasons discussed. But it is undeniably added complexity.
I don't agree that it is. Here's the relevant production:
'-'_opt DecimalIntegerLiteral JSONFraction_opt ExponentPart_opt
Notice that this reuses DecimalIntegerLiteral from the ECMAScript
grammar, which as stated above already prohibits leading zero.
To allow leading zero interpreted as decimal, you would replace
DecimalIntegerLiteral here with DecimalDigits. But since that would add
another way (besides the LS/PS issue) in which the JSON grammar would
not be a subset of the ES5 grammar, it would be more complex than
rejecting leading zero, not less.
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the es5-discuss