Implement floats

[ruuda]

This is a work in progress, I’ll update the description later.

• TODO: Write something about the implementation (decimal, rational, ...)
• TODO: Write something about the types (Float, Num)

• Find "json superset" caveats and update them — it’s finally practically true.
• Ensure the fuzzer discovers new interesting code paths and that dictionaries are up to date.
• Ensure test coverage.
• Ensure grammars are up to date, for types as well as syntax.
• Ensure documentation is up to date.

Open questions

How should (in)equality between numbers interact with their identity? If we allow 10 < 11.0 to typecheck and produce the result you’d expect, then we should also allow 10 == 10.0, and {10, 10.0} But what should they produce? Numerically they are equal, but as runtime::Value, they are different values. I see two possible ways forward:

• Erode the difference between Int and Float further. Possibly only keep a Num type after all and everything is a float. 10 and 10.0 are equal, {10, 10.0} == {10}. This probably means that we print all numbers that are ints without suffix, which means that processing json is no longer “lossless” in the sense that we'd convert [10.0, 10] into [10, 10]. That sounds like something that will cause problems, hmmm ...
• Do not allow Int and Float to mix so implicitly. 10 < 11.0 is a type error. 10 == 10.0 is false for the same reason that 10 == "10" is false. (Which makes sense and is consistent in one way, but may be surprising in another.) {10, 10.0} is a set with two elements.

I’m leaning towards the second one, but on the other hand, am I making my own life difficult? Why have both Int and Float? I think primarily to add additional type-safety in schemas (for things like ports, or counts, non-integers make no sense). But if that’s the argument, then should there also be UInt? Uint16? Fin n? ...

What does Python do here? It has different runtime representations, but considers the values equal, and for sets the first value is preserved:

>>> {10, 10.0}
{10}
>>> {10.0, 10}
{10.0}

Cue treats 10.0 as not an int, even though it is equal to the integer 10:

$ cue eval -
x: int
x: 10.0
x: conflicting values int and 10.0 (mismatched types int and float):
    -:1:4
    -:2:4

$ cue eval -
10.0 == 10
true

Thinking out loud, a possible solution may be:

• There are only two numeric types: Int and Float (or maybe Float should be called Num), and Int is a subtype of the more general one.
• There is only one runtime representation, all numbers are implemented as Decimal.
• Decimal should preserve some presentation information that does not affect its identity, in particular the number of decimals. This way 10.0 and 10 can both be represented, and preserved exactly, for lossless json processing.
• For runtime checks, if we have a Num and expect an Int, we need to do more than just a type check; we should also change the presentation attribute to render it with zero decimals. This feels ad-hoc though. An alternative is to do what Cue does and verify the presentation attribute as part of the type check.