Re: [Json] JSON and int64s - any change in current best practice since I-JSON

[Carsten Bormann <[e-mail]>]

On 2024-01-17, at 18:06, Joe Hildebrand <[e-mail]> wrote:
> 
> It may be an implementation detail which type gets generated from parsing. 

Once there is an application that gives different semantics to 1n in a specific place than to 1, it is no longer an implementation detail at all.

There is a large swath of JSON implementations that bin JSON numbers without dots or exponents into an integer bin and those with at least one of them into a floating point bin.  I’ll call this “syntactic boundary”.

10 and 10.0/1e1/0.1e2 are different with these implementations.

JavaScript gives all these numbers the exact same meaning; it doesn’t have a boundary at all (until you start using | and similar, which then mogrifies into 32-bit integers, IIRC).

(JSON doesn’t give any meaning to numbers, but it seems to imply that they are somehow standing for the mathematical concept of a number without mentioning the computer concept of separate integer and floating point types.
So one might think that JSON favors the JavaScript interpretation.
But then Section 7 of RFC 8259 says:

   The representation of numbers is similar to that used in most
   programming languages.

… where most programming languages have a rather thick firewall between integers and floating point numbers.)

>  The questions for interop are:
> 
> - are long integers without prefixes allowed or cause a parse error?

JSON certainly allows them, so if ESON wants to be a superset, they need to be allowed.

> - if they are allowed, are they expected to have (somewhat unspecified) JSON behavior, or are they expected to behave in int-like fashion?

There is no JSON behavior.  They are numbers, "similar to that used in most programming languages”.

There is the common practice of binning non-dot, non-exponent numbers into the int-like bin (syntactic boundary).  There also is the JavaScript behavior.  One could imaging a semantic boundary, where 10/1e1/0.1e2/10.0 are integers because they are integral numbers, and only non-integral numbers are floating point — see the dCBOR discussion over at the CBOR mailing list for one such model of applications.

> - are long numbers with decimals or exponents allowed, or cause a parse error?

They are allowed in JSON.

> - same as ints, what is their expected behavior?

Depends on where ESON puts the integer/float boundary — on syntactic grounds (like many non-JavaScript implementations).
This gets interesting again with 1e1000 (a common way to say “Infinity” in JSON, which doesn’t have Infinity).

> Part of this depends on how much you want to be backward-compatible with JSON.

Indeed.  I think trying to be backwards compatible with all (syntactically) JSON documents creates an interesting decision space.  Or maybe JSON/ECMA404 (syntax) is less important than semantic compatibility.

Grüße, Carsten