"Fortunately we have JSON now."
Which doesn't support big ints. JSON isn't a silver bullet.
{ "mybigint" : -123434580239458203948203982345723458 }
There is no reason to write a JSON parser that doesn't accept bignum integers, in a language that has them.
There are only two reasons some JSON implementation doesn't accept them. One is that the underlying software doesn't handle them. In that case JSON is moot; it's a limitation of that system. You cannot input bignums into that system through any means; they are not representable. The other is that the JSON implementation was written by obtuse blockheads: bignums could easily be supported since the underlying language has them, but aren't simply for compliance with the JSON specification. Compliance can be taken to counterproductive extremes.
import 'dart:convert';
main() {
print(JSON.decode('{ "mybigint" : -123434580239458203948203982345723458 }')['mybigint']);
}
>>> import json
>>> json.loads('{ "mybigfloat" : -1' + "8"*310 + '.0}')
{u'mybigfloat': -inf}Couldn't you write that about about almost any data type in JSON? The entire point of having a standard for such things is so that you don't have to worry about the differences between individual parsers/serializers.
That makes this an interesting case. As pointed out elsewhere, adamtulinius is randomly passing on an easily-falsified urban legend; the JSON standard explicitly allows bignums. That doesn't leave much room for not having to worry about the differences between individual parsers; if the language doesn't allow bignums, it's not going to parse them no matter how much it wants to be standards-compliant.
Yes, you could.
> The entire point of having a standard for such things is so that you don't have to worry about the differences between individual parsers/serializers.
Things like the maximum size of strings or integers are implementation limits. These should be kept separate from the language definition per se.
There are de facto different levels of portability of JSON data. A highly portable piece of JSON data confines itself not to exceeding certain limits, like ranges of integers. We could call that "strictly conforming".
JSON data which exceeds some limits is not strictly conforming, but it is still well-formed and useful.
Limits are different from other discrepancies among implementations because it is very clear what the behavior should be if the extended limit is supported. If an implementation handles integers beyond the JSON specified range, there is an overwhelming expectation that those representations keep denoting integers.
This is different from situations where you hit some unspecified or undefined behavior, where an implementation could conceivably do anything, including numerous choices that meet the definition of a useful extension.
At least with integers, I think protobuf's ability to specify 32-bit and 64-bit integers has been quite helpful.
> There are de facto different levels of portability of JSON data. A highly portable piece of JSON data confines itself not to exceeding certain limits, like ranges of integers. We could call that "strictly conforming".
Yeah... and that's how you get yourself in to problems. Life is simpler with one standard that either works or doesn't. Easily the most annoying thing with protocol buffers is using unsigned integers because of Java's signed integer foolishness. Yes, you can argue that's a reason to have the "strictly conforming" concept, but I'd argue quite the opposite.
> Limits are different from other discrepancies among implementations because it is very clear what the behavior should be if the extended limit is supported. If an implementation handles integers beyond the JSON specified range, there is an overwhelming expectation that those representations keep denoting integers.
Hmm... I don't think that is clear at all. In fact, it isn't clear to me when I have to worry about floating point rounding potentially kicking in.
> This is different from situations where you hit some unspecified or undefined behavior, where an implementation could conceivably do anything, including numerous choices that meet the definition of a useful extension.
In practice, there seems to be little difference. While there might be some idealized behaviour that is expected, there appears to be plenty of wiggle room for a variety of behaviours for these "not strictly conforming" cases.
In fact numbers have no semantic meaning applied to them in JSON. Probably the only reason to include them is to standardize their representation as a debugging aid.
On other trick is that because comments aren't supported is to make a keys named "//SomeComment":"", this will still be syntactically correct json and you can simply ignore them inside your program.
JSON is missing a lot of little things, but once you add them in you end up with something that is a lot harder to parse, which ultimately hurts the ubiquitous appeal of json.
>>> json.loads("NaN")
nan
>>> json.loads("Infinity")
inf
>>> json.loads("-Infinity")
-inf
>>> json.loads("1234567890"*20)
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
12345678901234567890L
> Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.
- http://www.ecma-international.org/publications/files/ECMA-ST...
https://docs.python.org/2/library/json.html#standard-complia...
It does claim that the support for arbitrary precision numbers is standards-compliant. Looking at the ECMA standard briefly, that seems to be correct to me: the official JSON grammar does allow arbitrary-precision, and disclaims restrictions on how a particular programming language interprets numbers.
I have to admit that I'm kind of concerned about the NaN and Infinity issue because I thought there was more uniformity among JSON parsers about what is or isn't legitimate JSON.
<succ>
<succ>
<succ>
<zero></zero>
</succ>
</succ>
</succ>