Unintuitive JSON Parsing • Hacker News Board

Re: Unintuitive JSON Parsing

#31

Post by reificator » Sat, Dec 28, 2019, 9:40 PM UTC

johnhenry wrote: post #27

> Either the leading zero is ignored, or it indicates octal, as it does in many languages, including JavaScript. This is false. In JavaScript, a leading zero, unless accompanied by a lowercase oh ('o') does indicate the number is written in octal. 08 === 0o10; // true Here, the left side is still base 10, while the right side is base 8.

I wouldn't say it's false, I would say it's no longer true in strict mode.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Javascript for many years has assumed a leading zero means an octal prefix, and it's only recently that behavior has changed.

EDIT: Also your example does not disprove this. Here's another example that you should try running in the console:

    011 === 11; // false
    011; // 9

Re: Unintuitive JSON Parsing

#32

Post by samatman » Sat, Dec 28, 2019, 9:40 PM UTC

johnhenry wrote: post #27

> Either the leading zero is ignored, or it indicates octal, as it does in many languages, including JavaScript. This is false. In JavaScript, a leading zero, unless accompanied by a lowercase oh ('o') does indicate the number is written in octal. 08 === 0o10; // true Here, the left side is still base 10, while the right side is base 8.

It's not false, because it's perfectly reasonable to describe both ES5 and ES6 as "JavaScript".

It is, at best, no longer true.

Re: Unintuitive JSON Parsing

#33

Post by jchook » Sat, Dec 28, 2019, 9:41 PM UTC

will4274 wrote: post #13

wereHamster wrote: post #8

Earlier quoted context omitted.

According to the proposal, this has been shipped in V8 in Chrome 66 (from the V8 bug report: The ECMAScript ⊃ JSON proposal shipped in V8 v6.6 and Chrome 66). And yet my Chrome version 79 does not parse "[01]", throws the same error as described in the article. Same error in Node 12.14.0 (which includes V8 7.7.299.13). Something doesn't add up.

Not sure what's confusing. "[01]" is not valid JSON. JSON being a subset of JavaScript means that all valid JSON constructs are valid JavaScript constructs. So, the subset statement says nothing at all about "[01]"

That said, in theory, shouldn't:

JSON.parse("0o10") === 8?

I get SyntaxError: Unexpected token o in JSON at position 1

Re: Unintuitive JSON Parsing

#34

Post by microcolonel » Sat, Dec 28, 2019, 9:53 PM UTC

nicoburns wrote: post #2

> The parser will not complain about leading zeros because JSON has no concept of leading zeros. Of course there is no logical reason why the parser shouldn't have this concept just because the spec doesn't require. IMO, beyond basic correctness, user friendly error messages are the main differentiator between excellent parsers and crappy parsers.

When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection.

Helpful error messages for humans writing JSON is a special use case, not "the main differentiator" marking an "excellent [parser]".

Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black hole. An "excellent" parser might even reject some technically valid forms, for not being regular (indicating a suspicious or malfunctioning client).

Re: Unintuitive JSON Parsing

#35

Post by faho » Sat, Dec 28, 2019, 9:57 PM UTC

ComputerGuru wrote: post #15

So is it incorrect (Technically, at any rate) for a parser to support leading zeroes in its implementation?

RFC8259 allows arbitrary extensions, so as long as it doesn't cause any misparses of regular JSON it would be acceptable, at least up to that standard.

Re: Unintuitive JSON Parsing

#36

Post by [deleted] » Sat, Dec 28, 2019, 9:58 PM UTC

will4274 wrote: post #11

Why is concatenated json a thing? In what sense is: {0}{1} better than [{0},{1}]? Presumably, if a few bytes are a major concern, you aren't using JSON anyway.

[deleted]

Re: Unintuitive JSON Parsing

#37

Post by ufedvjot13467 » Sat, Dec 28, 2019, 10:02 PM UTC

jchook wrote: post #33

will4274 wrote: post #13

Earlier quoted context omitted.

Not sure what's confusing. "[01]" is not valid JSON. JSON being a subset of JavaScript means that all valid JSON constructs are valid JavaScript constructs. So, the subset statement says nothing at all about "[01]"

That said, in theory, shouldn't: JSON.parse("0o10") === 8? I get SyntaxError: Unexpected token o in JSON at position 1

No. Valid json is valid JavaScript. Valid JavaScript is not, necessarily, valid json.

Re: Unintuitive JSON Parsing

#38

Post by frenchy » Sat, Dec 28, 2019, 10:03 PM UTC

quotemstr wrote: post #19

I think JSON would be vastly improved if it were to just allow comments. Maintaining configuration in JSON is unnecessarily painful due to this pointless feature gap.

If you're maintaining a configuration file in JSON format, you're using the wrong tool for the job. I know a certain popular package manager does exactly this, but popular doesn't necessarily mean well designed.

Re: Unintuitive JSON Parsing

#39

Post by [deleted] » Sat, Dec 28, 2019, 10:05 PM UTC

jchook wrote: post #33

will4274 wrote: post #13

Earlier quoted context omitted.

Not sure what's confusing. "[01]" is not valid JSON. JSON being a subset of JavaScript means that all valid JSON constructs are valid JavaScript constructs. So, the subset statement says nothing at all about "[01]"

That said, in theory, shouldn't: JSON.parse("0o10") === 8? I get SyntaxError: Unexpected token o in JSON at position 1

[deleted]

Re: Unintuitive JSON Parsing

#40

Post by vjeux » Sat, Dec 28, 2019, 10:11 PM UTC

spankalee wrote: post #6

nicoburns wrote: post #2

> The parser will not complain about leading zeros because JSON has no concept of leading zeros. Of course there is no logical reason why the parser shouldn't have this concept just because the spec doesn't require. IMO, beyond basic correctness, user friendly error messages are the main differentiator between excellent parsers and crappy parsers.

Browser JSON parsers probably shouldn't be optimized for user friendliness, since to the users running the program any error message is going to be unfriendly. They are optimized for speed, and if nice error messages slow thing down at all, then bare messages it is. Maybe there's a way to re-parse with a friendly parser with there's an error and dev tools is open.

In a language I worked on ( github.com/skiplang/skip ), at the moment where we throw a syntax error, we can look at the previous few tokens and generate much better error message.

In the case of the above, if last is ], previous is number and before is 0, then put a nice error message where octal notation is not allowed.

This is not “pure” from a language theory sense but in practice if you add a handful of common ones, it makes for a much better experience.