Hacker News Reader

Comment by kazinator | Hacker News Reader

Sure it does:

  { "mybigint" : -123434580239458203948203982345723458 }

You can throw the spec out the window and put as many digits as you want into a JSON integer. Any half decent parser in a half decent language will accumulate the token and spit out an integer object.

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.

View on HN

For example:

    import 'dart:convert';
    
    main() {
      print(JSON.decode('{ "mybigint" : -123434580239458203948203982345723458 }')['mybigint']);
    }

Prints -123434580239458203948203982345723458

What does it do for large floats? In Python:

    >>> import json
    >>> json.loads('{ "mybigfloat" : -1' + "8"*310 + '.0}')
    {u'mybigfloat': -inf}

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

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

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

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

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

Reply on news.ycombinator.com