10 ms·

I wish this (and JSON) wouldn't be ambiguous about number type (integers vs. floating point.) There are very different types of data in my opinion.

neoeldex 9y 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.
- protonfish 9y ago
  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.
- cabalamat 9y ago
  > 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.
  - jerf 9y ago
    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....
    - thaumasiotes 9y ago
      > 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.
- dragonwriter 9y ago
  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.
jbob2000 9y ago
I disagree. For 99% of applications, a number is a number is a number. Integers and floating points are a leaky abstraction, I expect the language/compiler to handle these.
- iainmerrick 9y ago
  I'd put it at more like 50% of applications.
- rootbeerfloat 9y ago
  You’re the reason why floating point rounding errors happen.
- dmm 9y ago
  Try passing around 64bit integers in json. The majority of json implementations only implement double float numbers and will mangle your 64bit ints. The usual solution is passing int64s as strings, nasty.
  - colanderman 9y ago
    Those implementations are as broken as a database that stores ZIP codes as integers.
    - dmm 9y ago
      Hit F12 on chrome and enter the following: JSON.parse('[9223372036854775805]')[0] === JSON.parse('[9223372036854775806]')[0] You should get: <- true Is chrome's implementation broken? Those are both numbers that a signed int64 can store precisely but a double float cannot.
      - colanderman 9y ago
        Yes, the JavaScript JSON parser is broken (in design), in that it silently loses data/precision of JSON numbers. JSON numbers are not "int64s" or "double floats", they are arbitrary-precision decimal values. [1] Postgres is the only popular system with built-in JSON functionality that I know of to correctly round-trip JSON numeric data. Python comes close but fails for any number with a decimal point or in E-notation. One can argue that the JSON spec is too permissive (and I would disagree, though I'm somewhat a purist). Or a pedant could note that the JSON spec doesn't actually say whether any of the digits in a number are considered to carry information (and does in fact note that many parsers are faulty). But it's unfortunately true that most popular JSON parsers fail to round-trip valid JSON data due to flawed design. [1] http://json.org/ http://json.org/
zitterbewegung 9y ago
A numeric tower could be useful. https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower
- vorotato 9y ago
  C R Q Z N Complex, Real, Rational, Integer, Natural
greggirwin 9y ago
This comment has generated a lot of interest, and rightly so. The thing to remember is that Ren (and JSON) are data exchange formats, not in-memory representations. If you need more control than their numeric syntax supports, metadata is your friend. Just include that where needed. That doesn't mean every endpoint will honor or treat them the same, of course.
- specialist 9y ago
  "...are data exchange formats, not in-memory representations." Real world values are still typed. "If you need more control ... metadata is your friend." aka implicit user typedefs. Explicit is better.
  - greggirwin 9y ago
    Explicit is different, not better.
Yaggo 9y ago
Because JSON is a text format, nobody prevents you from encoding floats like this: { "int": 1, "float": 1.0 } Of course it's up to the parser implementation to interpret 1.0 as a float. The spec is very relaxed about the number type: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6

neoeldex 9y 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.

protonfish 9y ago
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.
cabalamat 9y ago
> 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.
- jerf 9y ago
  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....
  - thaumasiotes 9y ago
    > 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.
dragonwriter 9y ago
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.

jbob2000 9y ago

I disagree. For 99% of applications, a number is a number is a number. Integers and floating points are a leaky abstraction, I expect the language/compiler to handle these.

iainmerrick 9y ago
I'd put it at more like 50% of applications.
rootbeerfloat 9y ago
You’re the reason why floating point rounding errors happen.
dmm 9y ago
Try passing around 64bit integers in json. The majority of json implementations only implement double float numbers and will mangle your 64bit ints. The usual solution is passing int64s as strings, nasty.
- colanderman 9y ago
  Those implementations are as broken as a database that stores ZIP codes as integers.
  - dmm 9y ago
    Hit F12 on chrome and enter the following: JSON.parse('[9223372036854775805]')[0] === JSON.parse('[9223372036854775806]')[0] You should get: <- true Is chrome's implementation broken? Those are both numbers that a signed int64 can store precisely but a double float cannot.
    - colanderman 9y ago
      Yes, the JavaScript JSON parser is broken (in design), in that it silently loses data/precision of JSON numbers. JSON numbers are not "int64s" or "double floats", they are arbitrary-precision decimal values. [1] Postgres is the only popular system with built-in JSON functionality that I know of to correctly round-trip JSON numeric data. Python comes close but fails for any number with a decimal point or in E-notation. One can argue that the JSON spec is too permissive (and I would disagree, though I'm somewhat a purist). Or a pedant could note that the JSON spec doesn't actually say whether any of the digits in a number are considered to carry information (and does in fact note that many parsers are faulty). But it's unfortunately true that most popular JSON parsers fail to round-trip valid JSON data due to flawed design. [1] http://json.org/ http://json.org/

zitterbewegung 9y ago

A numeric tower could be useful. https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower

vorotato 9y ago
C R Q Z N Complex, Real, Rational, Integer, Natural

greggirwin 9y ago

This comment has generated a lot of interest, and rightly so. The thing to remember is that Ren (and JSON) are data exchange formats, not in-memory representations. If you need more control than their numeric syntax supports, metadata is your friend. Just include that where needed. That doesn't mean every endpoint will honor or treat them the same, of course.

specialist 9y ago
"...are data exchange formats, not in-memory representations." Real world values are still typed. "If you need more control ... metadata is your friend." aka implicit user typedefs. Explicit is better.
- greggirwin 9y ago
  Explicit is different, not better.

Yaggo 9y ago

Because JSON is a text format, nobody prevents you from encoding floats like this: { "int": 1, "float": 1.0 } Of course it's up to the parser implementation to interpret 1.0 as a float. The spec is very relaxed about the number type: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6