3 ms·
This is definitely a problem, but the place to solve it isn't Son. Son is intended to be a very simple project that grabs all the clear wins. Do we really need
by seagreen 9y ago
This is definitely a problem, but the place to solve it isn't Son.
Son is intended to be a very simple project that grabs all the clear wins. Do we really need both `0` and `-0`, stuff like that.
There are too many different things JSON Numbers can represent for us to have a clear strategy for all them in Son. Int64s, doubles, floats, arbitrary precision numbers (eg https://hackage.haskell.org/package/scientific-0.3.5.2 https://hackage.haskell.org/package/scientific-0.3.5.2), etc. That makes this a good for for the schema layer (eg JSON Schema or whatever you're using), not the base specification layer.
- patrec 9y ago> Do we really need both `0` and `-0`, stuff like that. Well, yeah since signed zeros are a thing. Chrome: > JSON.parse('-0.0') -0 > JSON.parse('0.0') 0 python: In [3]: json.loads('-0.0') Out[3]: -0.0 In [4]: json.loads('0.0') Out[4]: 0.0
- patrec 9y ago> This is definitely a problem, but the place to solve it isn't Son. But then what problem does Son actually solve? How is a canonicalisation format that's not actually canonical useful? You take a hit (e.g. by forgoing fast existing libraries, control over pretty printing, and by being forced to sort on serialization which screws up streaming), but gain essentially nothing, not even the advertised benefit of your stuff not randomly changing as it moves through the stack. The likely main benefit of canonicalization is for security and crypto, but unless you use son without numbers (or create your own subset of son) it's kinda useless for that. Of course you can just encode all your numbers in strings or something, but at the point where you're doing your own number parsing logic (which is the hardest bit), why not just use some well-designed actually canonical format like csexp?