Hacker News new | ask | show | jobs
by neoeldex 3159 days ago
They are different data types, but integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit. Its about your use case, and when your parsing something with loose typing into stricter types, make sure you validate accordingly. But being able to specify the exact type kind of defeats the purpose of an interchangeable data format.
3 comments

Not really; those int types differ in range, but while that matters for a schema format, it doesn't really for an interchange format.

OTOH, exact decimals (of which integers are a subset) differ fundamentally in meaning from limited precision binary (or decimal, though that's more rarely encountered) floating point approximations. Which matters in interchange as well as schema.

Yes, the specific type of integer and floating-point can vary, but how operators work and display formatting should be consistent. For example, Modulo should be integer-specific, and the concept of precision only applies to floating-point numbers.
> integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit

These are all integers. There only needs to be one integer type for all of: 0 6 -6 8000000000000000000000. Python gets this right.

Now 90%+ of the programming language communities have a bar to implement your specification, because they have to emit a weird type out of the deserializations that will break code in weird ways, and in the case of static languages, you may have created a deserialization format that always emits BigInts (several words of memory and possible a mandatory indirection based on implementation) and will thus be unable to compete on the benchmarks against the serialization formats that specified integer sizes. And your serialization format is that much closer to withering on the vine with no usage.

Or you can go the JSON route, mumble your way through the numbers spec, let every language do its own thing, and tell the handful of people seriously interested in moving integers too large to be precisely specified by a 64-bit float to encode as strings or something and stop worrying everyone else with the complexity....

> in the case of static languages, you may have created a deserialization format that always emits BigInts

I don't follow this one. If your language, static or otherwise, is capable of turning this JSON:

    "100"
into a string, and this:

    100
into a number of whatever type, then it's also capable of turning this hypothetical input:

    100
into one type of integer, and this:

    100000000000000000000000000000000000000000000000000000000
into another type of integer.