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.
Unintuitive JSON Parsing
11–20 of 77 posts
Re: Unintuitive JSON Parsing
#12In cases like this, the parser and lexer can often produce a better error message if they are written to accept a more lax input and then check it for errors. For example, instead of faithfully implementing the grammar from the specification, allow numbers with leading zeroes and then produce an error for them. Another situation where this comes up is parsing language keywords. Instead of writing a separate lexer rul…
> instead of faithfully implementing the grammar from the specification, allow numbers with leading zeroes and then produce an error for them.
But that's the problem. The tokenizer doesn't talk to the grammar parser (and vice versa)
The tokenizer could understand numbers with leading zeroes and throw an error there.
Something to think about: do languages - not json - interpret -1.2 as [MINUS][NUMBER] or just [NUMBER]. Or how does languages deal with 1.0-2.0 compared to 1.0+-2.0
Re: Unintuitive JSON Parsing
#13The article leads with an incorrect statement. JSON is now a subset of JavaScript: https://github.com/tc39/proposal-json-superset
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]"
Re: Unintuitive JSON Parsing
#14Why 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.
Streaming is the prime use case.
Re: Unintuitive JSON Parsing
#15So is it incorrect (Technically, at any rate) for a parser to support leading zeroes in its implementation?
Re: Unintuitive JSON Parsing
#16What possible reason could someone have for wanting to do this? It is explicitly not recommended in JavaScript:
https://developer.mozilla.org/Web/JavaScript/Reference/Error...
See for yourself:
> 'use strict'; 01;
SyntaxError: "0"-prefixed octal literals and octal escape sequences are
deprecated; for octal literals use the "0o" prefix insteadRe: Unintuitive JSON Parsing
#17In cases like this, the parser and lexer can often produce a better error message if they are written to accept a more lax input and then check it for errors. For example, instead of faithfully implementing the grammar from the specification, allow numbers with leading zeroes and then produce an error for them. Another situation where this comes up is parsing language keywords. Instead of writing a separate lexer rul…
> instead of faithfully implementing the grammar from the specification, allow numbers with leading zeroes and then produce an error for them. But that's the problem. The tokenizer doesn't talk to the grammar parser (and vice versa) The tokenizer could understand numbers with leading zeroes and throw an error there. Something to think about: do languages - not json - interpret -1.2 as [MINUS][NUMBER] or just [NUMBER]…
Exactly. I was referring to the grammar the tokenizer uses for tokenizing numbers. Instead of faithfully copying the JSON spec, you could use a simpler rule that also accepts leading zeros.
As for the leading "-", in languages that have expressions it is common to parse the "-" as a prefix operator because that covers both negative numbers (-1.0) and negating variables (-x).
But in JSON there are no expressions like 1.0-2.0 so the leading "-" is parsed as part of the number.
Re: Unintuitive JSON Parsing
#18In cases like this, the parser and lexer can often produce a better error message if they are written to accept a more lax input and then check it for errors. For example, instead of faithfully implementing the grammar from the specification, allow numbers with leading zeroes and then produce an error for them. Another situation where this comes up is parsing language keywords. Instead of writing a separate lexer rul…
This seems more flexible to me somehow. Using the approach in TFA, can the laser handle tokens that are prefixes of other tokens? Or even tokens that share prefixes? Lexing "truefalse" as two adjacent tokens "true" and "false" seems slightly crazier than just lexing it as one (meaningless) token.
Usually, if there is a token that is a prefix of another the longer token wins. For example, in Javascript --x is parsed as the decrement operator instead of as two unary "-" operators.
Re: Unintuitive JSON Parsing
#19I 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.
Re: Unintuitive JSON Parsing
#20Why 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.
If you have a file or network stream with millions of separate JSON items, then you might want to parse and process each item separately as it is received, and the surrounding structure just gets in the way. That being said, it's properly better to explicitly acknowledge that you're using something-like-json-but-not-really-json like http://jsonlines.org does instead of simply concatenating json objects.