Howdy, I'd like to present a minimal JSON encoding/decoding library: http://hackage.haskell.org/package/yocto-0.1.2
From the README:
Yocto is exceedingly simple: it only exports one type, Value (which can represent any JSON-encoded data) in addition to Read and Show instances for it--which, respectively, take care of decoding and encoding values automatically. It's worth mentioning that Yocto handles numbers as Rationals rather than Doubles, which makes it faithful to the JSON standard and lets it handle rational numbers of arbitrary magnitude and precision. The name is a play on metric unit prefixes: AttoJson is a tiny JSON library, and Yocto is even smaller. (The entire implementation fits in fewer than 80 lines x 80 columns.) [It is meant primarily for interactive use and one-offs, which is how I'm handwaving hijacking Read and Show.] Anyway, I hope you find it useful; the code lives here: https://github.com/ajg/yocto Alvaro http://alva.ro
I like it a lot and just used it to help somebody intimidated by Parsec in the IRC channel. Still cringing at the read/show :) On Tue, Jan 28, 2014 at 11:57 AM, Alvaro J. Genial <genial@alva.ro> wrote:
Howdy,
I'd like to present a minimal JSON encoding/decoding library:
http://hackage.haskell.org/package/yocto-0.1.2
From the README:
Yocto is exceedingly simple: it only exports one type, Value (which can represent any JSON-encoded data) in addition to Read and Show instances for it--which, respectively, take care of decoding and encoding values automatically.
It's worth mentioning that Yocto handles numbers as Rationals rather than Doubles, which makes it faithful to the JSON standard and lets it handle rational numbers of arbitrary magnitude and precision.
The name is a play on metric unit prefixes: AttoJson is a tiny JSON library, and Yocto is even smaller. (The entire implementation fits in fewer than 80 lines x 80 columns.)
[It is meant primarily for interactive use and one-offs, which is how I'm handwaving hijacking Read and Show.]
Anyway, I hope you find it useful; the code lives here:
Alvaro http://alva.ro
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Tue, Jan 28, 2014 at 3:13 PM, Christopher Allen <cma@bitemyapp.com>wrote:
I like it a lot and just used it to help somebody intimidated by Parsec in the IRC channel.
Thanks, that's great to hear! Still cringing at the read/show :) Aye... if it helps, I'm open to typeclass suggestions. :) Alvaro http://alva.ro
On Tue, Jan 28, 2014 at 3:38 PM, Bryan O'Sullivan <bos@serpentine.com>wrote:
Don't use a typeclass at all: just write encode and decode functions.
Seems like a Codec class with such functions would be useful, perhaps analogous to the Binary class [1] but also suitable for textual encodings. Alvaro http://alva.ro [1] http://hackage.haskell.org/package/binary-0.7.1.0/docs/Data-Binary.html#t:Bi...
Are you bent on making it more elaborate/complicated than it needs to be? Why not just keep it encode/decode? On Tue, Jan 28, 2014 at 12:51 PM, Alvaro J. Genial <genial@alva.ro> wrote:
On Tue, Jan 28, 2014 at 3:38 PM, Bryan O'Sullivan <bos@serpentine.com>wrote:
Don't use a typeclass at all: just write encode and decode functions.
Seems like a Codec class with such functions would be useful, perhaps analogous to the Binary class [1] but also suitable for textual encodings.
Alvaro http://alva.ro
[1] http://hackage.haskell.org/package/binary-0.7.1.0/docs/Data-Binary.html#t:Bi...
On Tue, Jan 28, 2014 at 3:53 PM, Christopher Allen <cma@bitemyapp.com> wrote:
Are you bent on making it more elaborate/complicated than it needs to be?
Oh, I'm just thinking out loud. Why not just keep it encode/decode?
Yeah, that's a good suggestion; I may adopt it for 0.1.3. Alvaro http://alva.ro
Cool, thanks again for sharing this, I look forward to using it for teaching Parsec and Haskell :) On Tue, Jan 28, 2014 at 12:56 PM, Alvaro J. Genial <genial@alva.ro> wrote:
On Tue, Jan 28, 2014 at 3:53 PM, Christopher Allen <cma@bitemyapp.com> wrote:
Are you bent on making it more elaborate/complicated than it needs to be?
Oh, I'm just thinking out loud.
Why not just keep it encode/decode?
Yeah, that's a good suggestion; I may adopt it for 0.1.3.
Alvaro http://alva.ro
participants (4)
-
Alvaro J. Genial -
Bryan O'Sullivan -
Christopher Allen -
Tobias Florek