Add corner cases in the JS bridge

[cristianoc]

The tests document corner cases in the JS bridge (NaN, infinity, large), so one can assess whether they should be addressed. The .md document gives an overview of the cases.

[jberdine]

Do I understand correctly that the summary is that when serializing/deserializing NaN, Infinity, or integers not representable in 53 bits, we should either fail loudly or detect these as special cases and use some other encoding that we can reliably invert? For NaN that might be trickier, since there are lots of them, and some are signaling and some non-signaling, etc. For large integers, I suppose we could represent them using BigInt on the JS side, but it might be hard to tell how much trouble that could cause users due to the API differences between Number and BigInt, and we probably don't want to make everything a BigInt. Thoughts?

Once the desired end state is known, it would be good to adjust these tests to check for that end state, and commit them with expectations to fail for the moment.

[cristianoc]

Do I understand correctly that the summary is that when serializing/deserializing NaN, Infinity, or integers not representable in 53 bits, we should either fail loudly or detect these as special cases and use some other encoding that we can reliably invert? For NaN that might be trickier, since there are lots of them, and some are signaling and some non-signaling, etc. For large integers, I suppose we could represent them using BigInt on the JS side, but it might be hard to tell how much trouble that could cause users due to the API differences between Number and BigInt, and we probably don't want to make everything a BigInt. Thoughts?

Once the desired end state is known, it would be good to adjust these tests to check for that end state, and commit them with expectations to fail for the moment.

I guess it depends on what the philosophy is.
One example philosophy:

• do not crash the system because of bad data
• choose reasonable defaults in corner cases
• log potentially dangerous events.

[jberdine]

What about the following proposal:

• Serialize NaN and Infinity values as their IEEE float counterparts, rather than as strings or integers as done now
• Serialize large integers as the nearest floating point number, and log a warning that a large number was approximated

An issue is that code on the skip side will potentially receive a mix of integers and floats to work with when expecting just integers. Motivation to not make type-unsound assumptions about what the json actually contains in the skip code.

As a user, it will also potentially be hard to notice the approximation warnings, or know what to do about them. But I think that at least diligent users could test if the numbers they receive are actually ints in order to detect if approximation has happened, and react however is appropriate in context.