Hi Jeremy, Sorry if I was unclear. Rational is acceptable to me as the result of a JSON parse, but Double (which Aeson uses), is not. Also acceptable would be Data.Decimal.Decimal, or maybe one of the types from Data.Fixed. JSON doesn't specify a data type for numbers, only a format. Jeff

JSON numbers are not equivalent to JavaScript/ECMAScript numbers, even if they are nominally related; the key differences are that in JSON, numeric literals: (a) can have any non-zero number of digits, effectively making JSON numbers both unbounded and arbitrarily precise (though actual infinities cannot be represented); and (b) cannot represent values that are not composed of digits, like NaN. For that reason, most standard (fixed size/binary) numeric types like double are a poor choice to contain numeric values specified in JSON; in particular, the mismatch means that conversion can be lossy in both directions. Hope that helps! Alvaro On Tue, Apr 24, 2012 at 5:19 PM, Jeremy Shaw wrote:

Hello,

I could be wrong, but I think the only real numeric type in javascript is 'Number' which is a floating point number? Which is why Aeson and others insist on converting everything to a Double or other Rational number?

- jeremy

On Tue, Apr 24, 2012 at 3:46 PM, Jeff Shaw wrote:

...

Hello, Up until now I've been using Aeson, but I've found that its number type isn't going to work for me. I need to use decimal numbers while avoiding conversions from and to Double, which Aeson doesn't allow. There are quite a few more JSON libraries for Haskell, which all appear to use Rational for numbers, so I'm wondering if anyone can recommend one.

Thanks, Jeff

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Apr 25, 2012 at 10:42 PM, Richard O'Keefe wrote:

Note that the conversion *IS* lossy in practice. If you send a JSON message to a Javascript program, or a Python program, or a Go program (if I am reading src/pkg/encoding/json/decode.go correctly) what you get will be a 64-bit float. The Jackson parser for Java uses Double for numbers with a '.' or 'e' by default, although it can be configured to use BigDecimal.

If you want numbers outside the domain of finite 64-bit floats to travel unscathed through JSON, then you must control not only which languages are used at each end, but which versions of which libraries and how configured.

Right, for better or for worse, the absence of numeric semantics in the JSON standard means that what a number means is up to the implementation(s) involved, and the onus is on the user(s) to coordinate between them.

I argued the other end of this in the mailing list for another language, saying that I wanted things that look like integers to be decoded as integers, and was stepped on hard. Some people found their programs much simpler if they always got the same kind of Number whatever the input looked like (in Jackson, a Number might be returned as an instance of any of five classes).

My view is that the only reasonable approach is to decode JSON numbers into arbitrarily-sized rationals, such that interpretation is arguably lossless (modulo loss of precision, if e.g. 1.0 cannot be distinguished from 1). Alvaro