Am 26.08.2014 16:40, schrieb Don:
On Tuesday, 26 August 2014 at 14:06:42 UTC, Sönke Ludwig wrote:
Am 26.08.2014 15:43, schrieb Don:
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
This would probably best added as another (CT) optional feature. I
think the default should strictly adhere to the JSON specification,
though.
Yes, it should be optional, but not a compile-time option.
I think it should parse it, and based on a runtime flag, throw an error
(perhaps an OutOfRange error or something, and use the same thing for
values that exceed the representable range).
An app may accept these non-standard values under certain circumstances
and not others. In real-world code, you see a *lot* of these guys.
Why not a compile time option?
That sounds to me like such an app should simply enable parsing those
values and manually test for NaN at places where it matters.
For all other (the majority) of applications, encountering
NaN/Infinity will simply mean that there is a bug, so it makes sense
to not accept those at all by default.
Apart from that I don't think that it's a good idea for the lexer in
general to accept non-standard input by default.
Please note, I've been talking about the lexer. I'm choosing my words
very carefully.
I've been talking about the lexer, too. Sorry for the confusing use of
the term "parsing" (after all, the lexer is also a parser, but anyway).
Part of the reason these are important, is that NaN or Infinity
generally means some Javascript code just has an uninitialized variable.
Any other kind of invalid JSON typically means something very nasty has
happened. It's important to distinguish these.
As far as I understood, JavaScript will output those special values as
null (at least when not using external JSON libraries).
No. Javascript generates them directly. Naive JS code generates these
guys. That's why they're so important.
JSON.stringify(0/0) == "null"
Holds for all browsers that I've tested.
But even if not, an uninitialized variable can also be very nasty, so
it's hard to see why that kind of bug should be silently supported (by
default).
I never said it should accepted by default. I said it is a situation
which should be *lexed*. Ideally, by default it should give a different
error from simply 'invalid JSON'. I believe it should ALWAYS be lexed,
even if an error is ultimately generated.
This is the difference: if you get NaN or Infinity, there's probably a
straightforward bug in the Javascript code, but your D code is fine. Any
other kind of JSON parsing error means you've got a garbage string that
isn't JSON at all. They are very different errors.
It's a diagnostics issue.
The error will be more like "filename(line:column): Invalid token" -
possibly the text following the line/column could also be displayed.
Wouldn't that be sufficient?
