Missing Number properties

[toastal]

Description of the change

No pun intended, a number of properties are missing from JavaScript’s
Number as seen here: https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-number.epsilon

This includes: EPSILON, NEGATIVE_INFINITY, MAX_VALUE, and
MIN_VALUE.

I have a current use case for MAX_VALUE.

---

Checklist:

• Added the change to the changelog's "Unreleased" section with a reference to this PR (e.g. "- Made a change (#0000)")
• Linked any existing issues or proposals that this pull request should close
• Updated or added relevant documentation
• Added a test for the contribution (if applicable)

[JordanMartinez]

Just a few thoughts:

• since this is adding FFI, how does this impact other backends?
• since this is adding FFI, it's technically a breaking change for other backends.

[toastal]

Questions I don't feel qualified to answer. They could be shimmed with their limits. Or don't use these values outside of a JS context. Or these could be moved to some sort of *-extra? I don't know the best solution but these are handy values in a JS context.

[JordanMartinez]

Hm... I feel like we keep running into this issue where the JS side should have stuff like this here, but I'm unsure how to proceed because it may affect other backends. However, adding another library containing a few functions seems dumb, too.

[JamieBallingall]

Numbers in Javascript (and hence Number in PureScript with a JS backend) are double-precision 64-bit binary format IEEE 754 values. That doesn't feel very backend-specific to me. I suspect that all backends will want to implement Number that way.

Of course, we want to minimize the number of times a backend implementer has to provide some special function or value. As part of the Math to Data.Number migration we are switching a bunch of values (such as ln2) from JS definitions to native PureScript definitions (so exports.ln2 = Math.LN2; in Math.js becomes ln2 = 0.6931471805599453 in Number.purs). Something similar should be possible here, with explicit native definitions of epsilon, maxValue, and minValue.

Since nan and infinity are defined by the backend, I think it is reasonable to have negativeInfinity defined that way too. Either that or omit it entirely and have users use -infinity.

I need to tidy up some documentation on #18 to get that over the line but would be happy to take the lead on this once I've done that. I expect that to be about a month from now.