Extend JSON to include Int64, UInt64, Arbitrary(String)

[peter-jerry-ye]

Spec

RFC 8259:

This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754 binary64 (double precision) numbers [IEEE754] is generally
available and widely used, good interoperability can be achieved by
implementations that expect no more precision or range than these
provide, in the sense that implementations will approximate JSON
numbers within the expected precision.

ECMA 404

JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of
number types of various capacities and complements, fixed or floating, binary or decimal. That can make
interchange between different programming languages difficult. JSON instead offers only the representation of
numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit
sequences even if they disagree on internal representations. That is enough to allow interchange.

Reference implementation

serde_json
gson
jackson
golang

Related

#1345

[peter-jerry-ye]

One possible solution is:

For FromJson and ToJson implementation in MoonBit, we guarantee roundtrip & lose no accuracy by:

• Using Double for UInt / Int
• Using String for UInt64 / Int64

For access custom data source (i.e. JSON shape isn't defined in MoonBit), we support them by adding a field to Number, something like:

enum Json {
  Number(Double, repr? : String)
}

And for users who wants to manipulate the number, they can handle the repr:

match json {
  { "a" : Number(-100..<100) } => ...
  { "a" : Number(_, repr~) } => ...
}

What do you think @gmlewis ?

[gmlewis]

That sounds good to me, @peter-jerry-ye - please feel free to close #1345 or let me know if you would like me to do anything to support this.

Thank you!

[peter-jerry-ye]

• UInt64 will need to wait for strconv: add uint/uint64 support #1411
• Int64 will be a breaking change as it currently uses Double

[peter-jerry-ye]

For supporting arbitrary precision numbers, the transition will take several releases

Release 1

• Add smart constructors for Json in the package builtin. The compiler will also need to switch to them @Yu-zh
• Deprecated constructors of Json. The compiler will need to emit warning for constructors or types @Yoorkin

Release 2

• Make Json pub instead of pub(all)
• Change Number(Double) to Number(Double, repr~ : String?), migrate smart constructor. The compiler will also need to make the change @Yu-zh