Added an instance for the 'Fixed' class.

parseJSON for the variations on ISO-8601 dates as listed in ECMA-262.

Add functions for inspecting Values

Added eitherDecode and eitherDecode'

Add elaborate guide to Data.Aeson's Haddock documentation

De-emphasize working directly with the Value type as this is not the
common (or recommended) way to use the library, but still include
documentation on how to use it when it's called for.

Since the documentation on using generics is documented in the FromJSON
and ToJSON classes, refer to that documentation instead of only
documenting one method (which is not the preferred method anymore with
default signatures I believe).

Improve introductionary documentation

Fixes haskell#68 and fixes haskell#66.

Add support for specifying how to encode datatypes in Data.Aeson.TH

Fix the Maybe being treated as ADT in Generics bug

…e pair

detect invalid UTF-8 encoding in JSON strings, throw appropriate error

…e object or array.

Tiny documentation patch, resolving small ambiguity.

This makes it easier to parameterize the generic JSON encoding/decoding
since users now don't need to import GHC.Generics
and so don't need to depend on ghc-prim.

I think this is a more sensible default.

- Better naming
- Clearer sectioning
- Some documentation
- Some implementation changes

The module is deprecated for the following reasons:

- It has issues: haskell#75, haskell#84, haskell#101, haskell#107.

- It's slow compared to GHC Generics and very, very, very slow
  compared to TH. See some recent benchmark results in haskell#116.

- The encoding/decoding can't currently be configured using the
  encoding Options.

- Related to the previous point: GHC Generics and TH use compatible
  encoders/decoders (if the same Options have been
  used). Data.Aeson.Generic does things slightly differently.

- The original author is not around to work on it.

This reflects its purpose more accurately.

- Rename "constructorNameModifier" to "constructorTagModifier".

- Rename "ObjectWithType" to "TaggedObject".

- Rename "typeFieldName" to "tagFieldName".

- Rename "defaultObjectWithType" to "defaultTaggedObject".

--HG--
rename : tests/Properties.hs => tests/Properties/Deprecated.hs

--HG--
extra : rebase_source : f086f5fb8c5249ec8c204d12d2856a79b40ebe5c

…her than json parser

* Is there supposed to be a "-" after Show? I had to remove it in order to compile my example.

* Clearly "Coord" is from one of the example applications and got missed in a copy-paste. It should be an instance for Person.

Coord -> Person

Fix lazy I/O leak and trailing garbage ignore bug in decode functions

--HG--
extra : rebase_source : 0fb1957085dc6026442518a0b76401b4b467e055
extra : amend_source : 762f5cacca19cff3b35a8b2f8945d3581a828910

Allow building with blaze-builder and older versions of bytestring
if the blaze-builder flag is specified.

Use the Builder from bytestring >= 0.10

Providing this instances is motived by the Haskell Report suggesting
that libraries ought to support tuples up to a size of 7
(see http://www.haskell.org/onlinereport/basic.html#basic-tuples):

> The Prelude and libraries define tuple functions such as zip for
> tuples up to a size of 7.

This fixes haskell#144

This follows up on 9ee73f3 by removing some more ByteString
related instances as suggested by @basvandijk in haskell#126.

The instances reuse the instance code for tuples.

I have noticed in multiple places around hackage that people add
these kinds of functions to get their JSON formatted keys (often
underscore_formatted_strings) out of Haskell's CamelCase data
properties (often withLongStringsOfCAPITALS).

I have also added to the .gitignore those files generated by the new
cabal 1.18 'sandbox' feature.

I have a few outstanding questions:

1) Should these functions live in another module with an isomorphic
inverse function, like `underscoreToCamel`? Like Aeson.Properties?
2) I am at something of a loss as to how to integrate testing into the
suite. I've tested the out at the REPL, but what steps should be
taken to integrate these into QuickCheck?

--HG--
extra : rebase_source : 4d92fc2b96527581ecba1a9d09e93a2c6ae31682
extra : amend_source : f2b002e759d692bc9bca962484123a7857ebbb02

Added FromJSON and ToJSON instances for Data.Tree.

--HG--
rename : Data/Aeson/Types/Class.hs => Data/Aeson/Types/Instances.hs

Scientific numbers are floating-point numbers with arbitrary precision
that are fast to parse and can be efficiently converted to/from
Fractional numbers like Doubles.

Change Number to Scientific

--HG--
rename : Data/Aeson/Types/Class.hs => Data/Aeson/Types/Instances.hs

The previous code used realToFrac (fromRation . toRational) which
approximates a floating point value. For example:

 > toRational (1.2::Double)
 5404319552844595 % 4503599627370496

If you encode this Rational number to a Scientific number and render it
you get:

 > encode (1.2::Double)
 "1.1999999999999999555910790149937383830547332763671875"

Using Scientific.fromFloatDigits you get the expected:

 > encode (1.2::Double)
 "1.2"

Encode RealFloat numbers using Scientific.fromFloatDigits

This fixes haskellgh-158.

--HG--
rename : release-notes.markdown => changelog

This gives us about a 20% performance increase when parsing an
array-heavy input, such as json-data/geometry.json (haskellgh-134).

This gives us a further 10% performance improvement when parsing
object-heavy inputs, e.g. json-data/twitter100.json (haskellgh-134).

Well, that was embarrassing - my rewrite wasn't quite as clever as
I thought!

This fix drops peak throughput, but it's still better than it was.

--HG--
extra : amend_source : ca3adc7f8e317f8db73170b08bc145247fa752ec

This drops use of the (<|>) combinator, and greatly reduces the
extent to which we allocate unused thunks. As a result, it improves
both runtime and heap usage significantly.

--HG--
extra : rebase_source : 62bc8759400db5a2bc644f5da3fe19c0d10d5d96

If we've already peeked at a byte, we don't need to check its value
a second time.

Conflicts:
	Data/Aeson/Types/Internal.hs

Fix "incomplete input" from decodeStrictWith

Added data instance to Value

Adding functions to TH to make CamelCase to under_score easier.

- only use it when compiling against bytestring >= 0.10.4.0
- speed improvement over bytestring-via-text encoding:
    factor 1.5 - 1.6 for japanase and english JSON messages
    factor 2         for integer encoding

- equal speed for encoding floats

The value truncated to milliseconds by rounding down

…g-builder

Feat encode via bytestring builder

--HG--
extra : amend_source : c1a49357128d6784becacab023c114fceee98abf

I want to be able to use this as a baseline to see how the new
versions of the libraries fare.

--HG--
extra : amend_source : 166f845a7d1d42ee33c646f6fa7034d853eefe60