3 ms·

> There is no reason to write a JSON parser that doesn't accept bignum integers, in a language that has them. Couldn't you write that about about almost any da

by cbsmith 12y ago

> There is no reason to write a JSON parser that doesn't accept bignum integers, in a language that has them. 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.

thaumasiotes 12y ago
> 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.
- cbsmith 12y ago
  I think, ironically, there are a lot of JavaScript based parsers that won't handle bignums all too well. ;-)
kazinator 12y ago
> Couldn't you write that about about almost any data type in JSON? 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.
- cbsmith 12y ago
  > Things like the maximum size of strings or integers are implementation limits. These should be kept separate from the language definition per se. 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.

by cbsmith 12y ago

thaumasiotes 12y ago

> 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.

cbsmith 12y ago
I think, ironically, there are a lot of JavaScript based parsers that won't handle bignums all too well. ;-)

kazinator 12y ago

> Couldn't you write that about about almost any data type in JSON? 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.

cbsmith 12y ago
> Things like the maximum size of strings or integers are implementation limits. These should be kept separate from the language definition per se. 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.