JSON library suggestions?

JSON library suggestions?

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.

Re: JSON library suggestions?

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?

> 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
> [hidden email]> http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: JSON library suggestions?

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.

Re: JSON library suggestions?

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.

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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: JSON library suggestions?

Have you emailed Bryan O'Sullivan and explained your problem? It
sounds to me like choosing Double was just the wrong choice and is a
design flaw that should be fixed in Aeson?

There are far too many JSON libraries on hackage already, and what
would be really useful (to me) is for the community to standardize on
one. I maintain a number of libraries that need some sort of JSON
library, and supporting all of them is not practical. So far aeson
seems like the best choice for the 'one true Haskell JSON library'. I
would be happy to invest effort in trying to address the shortcomings
so that we can try to get some sort of consensus. Usually I like
choice and flexibility.. but in terms of JSON libraries.. it seems
like the design space for a good JSON library is pretty small.

- jeremy

On Tue, Apr 24, 2012 at 4:51 PM, Jeff Shaw <[hidden email]> wrote:
> 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

Re: JSON library suggestions?

On 04/24/2012 09: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.

Hi,

Not sure that's helpful to you since it's a C binding solution, but i haven't
found anything that i could use related to JSON in Haskell since i wanted:

- event based parsing.
- DoS protection.
- integer and float represented as array of bytes.
- and last but not least break neck speed.

so i ended up binding my own C embedded library [1]. I could clean up my ugly
bindings and publish it somewhere if it's useful.
I do have a plan, someday, to experiment with a rewrite in haskell using the
exact same technique but the will and time to do so have lacked so far.

Re: JSON library suggestions?

On 25/04/2012, at 9:51 AM, Alvaro Gutierrez wrote:
> 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.

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.

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).

Re: JSON library suggestions?

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).