aeson-utils

Utilities for working with Aeson.

Version on this page:0.3.0.2@rev:5
LTS Haskell 16.31:0.3.0.2@rev:7
Stackage Nightly 2020-08-03:0.3.0.2@rev:7
Latest on Hackage:0.3.0.2@rev:7

See all snapshots aeson-utils appears in

BSD-3-Clause licensed by Silk. B.V.
Maintained by [email protected]
This version can be pinned in stack with:aeson-utils-0.3.0.2@sha256:ae9f74efc346334bcfc1124785765d9e2c4749da7d247500a3c168b46c4ad76c,958

Module documentation for 0.3.0.2

Used by 2 packages in nightly-2017-10-28(full list with versions):

aeson-utils

Build Status

A small package containing helpful addititions to aeson.

It provides eitherDecodeV and decodeV functions (analogous to eitherDecode and decode in aeson) that can be used to parse atomic JSON values at the top level. This is not strictly valid JSON, only objects and arrays are allowed at the top level in the specification, but aeson’s encode allows this already. This gives us the nice property decodeV . encode = Just.

The package also contains the .=? operator that you can use to optionally construct object pairs:

object (
  [ "a" .= foo
  , "b" .= bar
  ] ++ catMaybes
  [ "c" .=? mBaz
  , "d" .=? mQux
  ])

Finally it has a parseNumber function that converts a scientific into Either Integer Double in case you want to distinguish between integrals and fractionals.

Installation instructions

aeson-utils is available on hackage

cabal install aeson-utils

Changes

Changelog

0.3.0.2

  • Allow aeson 0.9.*. Because of the aeson release eitherDecodeV and decodeV now behave the same as eitherDecode and decode respectively, this package can still be used as a compatibility layer.

0.3.0.1

  • Allow attoparsec 0.13.*

0.3

  • The semantics of eitherDecodeV and decodeV have been changed to conform to aeson’s eitherDecode and decode: They now consume until end of input and strip trailing whitespace.

    This is necessary to remove ambiguity when decoding JSON-like values that are not necessarily properly formatted for JSON. For example, parsing a hexadecimal digit sequence that starts with digits but does not have double quotes should fail to parse rather than be interpreted as a number.

0.2.2.1

  • Allow attoparsec 0.12.*

0.2.2.0

  • Deprecate parseNumber in favor of Data.Scientific.floatingOrInteger
  • Re-export Data.Scientific.floatingOrInteger

0.2.1.1

  • Allow scientific 0.3.*