Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unintuitive JSON Parsing

nullprogram.com

Post reply on HN
Print view View original

41–50 of 77 posts

Re: Unintuitive JSON Parsing

#41

Post by dllthomas »

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.

> user friendly error messages are the main differentiator between excellent parsers and crappy parsers

It think parser quality is a matter of correctness, error messages, speed, and resource use. How much each of these are to be prioritized depends on application. I'm entirely with you that most of the time error messages matter a lot and are often worse than they should be.

Re: Unintuitive JSON Parsing

#42

Post by ekimekim »

svnpenn wrote: post #16

What 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 instead

Octal notation is traditionally used in several contexts - file mode probably being the most common. If you were writing a JSON object to describe a file to be created, and you were under the mistaken impression that JSON supported octal with a leading zero (like most languages), it would be entirely reasonable to write something like:

    {
        "path": "/foo",
        "mode": 0644,
        "contents": "bar"
    }

Re: Unintuitive JSON Parsing

#43

Post by zwkrt »

raverbashing wrote: post #12
ufo wrote: post #5

In 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]…

If you know you are expecting an expression, then it is easy for the parser to understand ‘-‘ as a unary negation if it is the first symbol, otherwise it must be a binary subtraction operator.

    Expr: ‘-‘ Expr {
            return -1 * $2;
            }
        | Expr ‘-‘ Expr {
            return $1 - $2;
            }
        | ‘(‘ Expr ‘)’ {
            return $2;
            }
        | ...

Re: Unintuitive JSON Parsing

#44

Post by svnpenn »

ekimekim wrote: post #42
svnpenn wrote: post #16

What 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 instead

Octal notation is traditionally used in several contexts - file mode probably being the most common. If you were writing a JSON object to describe a file to be created, and you were under the mistaken impression that JSON supported octal with a leading zero (like most languages), it would be entirely reasonable to write something like: { "path": "/foo", "mode": 0644, "contents": "bar" }

Yeah ok, but its also explicitly not allowed by the specification, both in text:

> A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.

and image:

https://json.org/img/number.png

as shown literally on the JSON home page:

https://json.org

I am all for good error handling, but at some point you do have to blame the user.

Re: Unintuitive JSON Parsing

#45

Post by spullara »

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.

Sadly user friendly error messages are often main differentiator between low-performance parsers and high-performance parsers.

Re: Unintuitive JSON Parsing

#46

Post by magicalhippo »

ChrisSD wrote: post #30
userbinator wrote: post #21

IMHO if it's not going to support octal anyway, it makes zero(!) sense to artificially limit/special-case things like this, because then it's much simpler and more consistent to have leading zeros behave like any other digit.

JSON was made to be "based on a subset" of Javascript. The only way to be compatible with JS while removing octals is to disallow leading zeroes entirely. Doing otherwise would lead to JSON and JS behaving differently with the same input. Of course, until recently JSON wasn't a strict subset of JS but that was an oversight rather than by design.

I've been programming for 30 years, across many different languages from assembler and up. I've yet to use octals for any code.

What am I missing out on? Why are they included in modern languages like JS?

Re: Unintuitive JSON Parsing

#47

Post by aliceryhl »

magicalhippo wrote: post #46
ChrisSD wrote: post #30

Earlier quoted context omitted.

JSON was made to be "based on a subset" of Javascript. The only way to be compatible with JS while removing octals is to disallow leading zeroes entirely. Doing otherwise would lead to JSON and JS behaving differently with the same input. Of course, until recently JSON wasn't a strict subset of JS but that was an oversight rather than by design.

I've been programming for 30 years, across many different languages from assembler and up. I've yet to use octals for any code. What am I missing out on? Why are they included in modern languages like JS?

I once used octals in php: I had to specify the permissions for some file, and those should be in octal.

I assume JS has it because so does everyone else.

Re: Unintuitive JSON Parsing

#48

Post by lilyball »

ChrisSD wrote: post #30
userbinator wrote: post #21

IMHO if it's not going to support octal anyway, it makes zero(!) sense to artificially limit/special-case things like this, because then it's much simpler and more consistent to have leading zeros behave like any other digit.

JSON was made to be "based on a subset" of Javascript. The only way to be compatible with JS while removing octals is to disallow leading zeroes entirely. Doing otherwise would lead to JSON and JS behaving differently with the same input. Of course, until recently JSON wasn't a strict subset of JS but that was an oversight rather than by design.

Not only that, but rejecting leading zeroes allows parsers to add octal support themselves by accepting the leading zero, just as how some JSON parsers extend JSON by allowing comments, or trailing commas, or NaN/+Inf/-Inf.

Re: Unintuitive JSON Parsing

#49

Post by setr »

spullara wrote: post #45
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.

Sadly user friendly error messages are often main differentiator between low-performance parsers and high-performance parsers.

Probably not for any great reason: worst case scenario is to simply use the fast parser, and when it fails, then go back to the end of the last successfully parsed expression, and run the the slow parser to get a good error.

That is, it's not terribly difficult to deal with the tradeoffs if your description of the problem is at all correct

Re: Unintuitive JSON Parsing

#50

Post by [deleted] »

raverbashing wrote: post #12
ufo wrote: post #5

In 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]…

[deleted]
Post reply on HN