Extend CoreFn's Int literal encoding with a stringified value

[natefaubion]

Summary

CoreFn's integer encoding encodes the Integer (unbounded) as a JSON Number literal. This is technically valid as JSON does not require Number bounds, but makes tooling across languages complicated. For example, stock JSON tooling for JS will only support a 64bit double (52 bit max integer), and anything outside that range is difficult to parse.

Motivation

It's not possible for tools like purescript-backend-optimizer to parse CoreFn JSON for backends which use unbounded integers with any of the stock JSON tooling available in the PureScript ecosystem as they all rely on builtin JSON.parse.

Proposal

purescript/src/Language/PureScript/CoreFn/ToJSON.hs

Lines 63 to 66 in 8ede652

	= object
	[ "literalType" .= "IntLiteral"
	, "value" .= n
	]

Extend this with a stringValue field which prints the value as a String, making it easier for tooling to parse this as a BigInt of some kind. The additional field is necessary to keep CoreFn backwards compatible.

[sigma-andex]

It's not possible for tools like purescript-backend-optimizer to parse CoreFn JSON for backends which use unbounded integers with any of the stock JSON tooling available in the PureScript ecosystem as they all rely on builtin JSON.parse.

Not sure if this helps you, but yoga-json is able to parse BigInt by passing a reviver function to JSON.parse.

[natefaubion]

Not sure if this helps you, but yoga-json is able to parse BigInt by passing a reviver function to JSON.parse.

Reviver functions don’t help here because it’s already a JSON Number. Reviver functions can’t recover the original JSON syntax in order to load a Number as a BigInt without losing precision.

[michaelficarra]

@natefaubion You may be interested in the Stage 3 proposal JSON.parse source text access which makes this possible through revivers. Stage 3 means recommended for implementation, and it is already available in Chrome stable.

[garyb]

Very cool!

[JordanMartinez]

@natefaubion You may be interested in the Stage 3 proposal JSON.parse source text access which makes this possible through revivers. Stage 3 means recommended for implementation, and it is already available in Chrome stable.

I still think it would be easier to just encode the value as a String.

[JordanMartinez]

@natefaubion While this issue is for an Integer value, should the same be done on a Number value, too?

[natefaubion]

I don't think so. Number values are Double which are IEEE floats, same as JS, so there's no precision issue.

[anttih]

This might be a slightly different incarnation of this issue I just came across while compiling the integers test suite using backend-optimizer (thus using corefn as input). The PS literal -2147483648 gets compiled to (negate 2147483648). That positive number literal doesn't fit the 32-bit Integer once it's converted to int with 2147483648|0. Changing the JSON representation to a string wouldn't actually help if the negative literal gets compiled to negate x, the damage is already done in the corefn.