JSON support for BigInt in ES6. Was: javascript vision thing
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
orlong
) - 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 contact at isiahmeadows.com, www.isiahmeadows.com
> 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 contact at isiahmeadows.com www.isiahmeadows.com On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren <anders.rundgren.net at gmail.com> 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 >> <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> >> 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 > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
@isiah, actionable items before stage-4 are currently being debated @ tc39/proposal-bigint#162
@isiah, actionable items before stage-4 are currently being debated @ https://github.com/tc39/proposal-bigint/issues/162 On Aug 1, 2018 14:00, "Isiah Meadows" <isiahmeadows at gmail.com> wrote: > > 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 > contact at isiahmeadows.com > www.isiahmeadows.com > > > On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren > <anders.rundgren.net at gmail.com> 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 > >> <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> > >> 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 > > es-discuss at mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180801/1ffa9b0c/attachment-0001.html>
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: tc39/proposal-bigint#162