Quantcast

JSON library suggestions?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JSON library suggestions?

Jeff Shaw
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Jeremy Shaw-3
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 <[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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Jeff Shaw
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Radical
In reply to this post by Jeremy Shaw-3
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 <[hidden email]> 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 <[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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Jeremy Shaw-3
In reply to this post by Jeff Shaw
Hello,

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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Vincent Hanquez
In reply to this post by Jeff Shaw
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.

[1] https://github.com/vincenthz/libjson

--
Vincent

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
ok
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

ok
In reply to this post by Radical

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



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JSON library suggestions?

Radical


On Wed, Apr 25, 2012 at 10:42 PM, Richard O'Keefe <[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Loading...