> Is 1 a byte, int, double, BigInt or BigNumber? You tell me! This obviously > has major consequences for parsers. However, as long as you stay with the > original JS Number scope everything works just fine.
BTW, most strongly typed languages parse numbers one of two ways: - If it's just digits, it's parsed as an integer (typically an `int` or `long`) - If it has floating point stuff, it's parsed as a float (typically a `double`) > Other people (including myself) are more pragmatic and pretty much dismiss > JSON Number as a suitable notation for numbers outside of the original JS > scope. This view is also aligned with most IETF and W3C standards to date > defining JSON structures. In general, JSON is great for prototyping protocols and easy serialization when performance *isn't* a major concern, but that's about it. (It's better than XML and more performant than it, but it's still needlessly complex to parse/serialize.) ----- Isiah Meadows [email protected] www.isiahmeadows.com On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren <[email protected]> wrote: > Richard et al, > > If we call the situation "limbo" or not isn't that important, I just happen > to have a preference for strong or funny expressions. > > The root of the problem (not only for JavaScript) is that JSON is *the only > general purpose data interchange format in existence* that uses a single > notion to signal "here comes a number". > > Is 1 a byte, int, double, BigInt or BigNumber? You tell me! This obviously > has major consequences for parsers. However, as long as you stay with the > original JS Number scope everything works just fine. > > One camp suggests that the right solution is to use some kind of BigNumber > as the underlying Number type which surely is one way dealing with *data > type overloading*. > > Other people (including myself) are more pragmatic and pretty much dismiss > JSON Number as a suitable notation for numbers outside of the original JS > scope. This view is also aligned with most IETF and W3C standards to date > defining JSON structures. > > Now to the challenge: Create a scheme that makes everybody happy! Well, to > be more realistic; create something that maybe nobody really likes, by > supporting BOTH of the opposing views. > > Feel free slashing my minuscule change proposal: > https://github.com/tc39/proposal-bigint/issues/162#issuecomment-408679884 > > Cheers, > Anders > On 2018-08-01 05:37, Richard Gibson wrote: >> >> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript >> JSON.parse implementation simply cannot accept e.g. 0n and still uphold the >> conformance guarantees <https://tc39.github.io/ecma262/#sec-json-object>: >> >> Conforming implementations of *JSON.parse* and *JSON.stringify* must >> support the exact interchange format described in the ECMA-404 specification >> without any deletions or extensions to the format. >> >> >> Both BigInt and Symbol lack native support in JSON, and although adding in >> custom serialization is relatively easy, custom parsing is not because >> JSON.parse doesn't expose the text used to produce a value. But in my >> opinion, it would be a mistake to characterize that explicit lack of support >> as "limbo". >> >> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> On 2018-07-28 00:34, Richard Gibson wrote: >> > As stated even more strongly in ECMA-404: >> > >> > Because it is so simple, it is not expected that the JSON >> grammar will ever change. This gives JSON, as a foundational notation, >> tremendous stability. >> > >> >> Richard, that's great but it doesn't completely respond to my "limbo" >> claim: >> >> https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html >> >> Take your pick! Whatever you come up with, I'm sure there will be some >> rotten tomatoes flying around :-) >> >> Cheers, >> Anders >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
