@@ -1,119 +0,0 @@
3− * The performance of encoding to and decoding of bytestrings
4− have both improved by up to 2x, while also using less
7− * New dependency: the scientific package lets us parse
8− floating point numbers more quickly and accurately.
10− * eitherDecode, decodeStrictWith: fixed bugs.
12− * Added FromJSON and ToJSON instances for Tree and Scientific.
14− * Fixed the ToJSON instances for UTCTime and ZonedTime.
18− * Much improved documentation.
20− * Angle brackets are now escaped in JSON strings, to help avoid XSS
23− * Fixed up handling of nullary constructors when using generic
26− * Added ToJSON/FromJSON instances for:
29− * ISO-8601 dates: UTCTime, ZonedTime, and TimeZone
31− * Added accessor functions for inspecting Values.
33− * Added eitherDecode function that returns an error message if
38− * This release introduces a slightly obscure, but
39− backwards-incompatible, change.
41− In the generic APIs of versions 0.4 and 0.5, fields whose
42− names began with a "_" character would have this character
43− removed. This no longer occurs, as it was both buggy and
44− surprising (https://github.com/bos/aeson/issues/53).
46− * Fixed a bug in generic decoding of nullary constructors
47− (https://github.com/bos/aeson/issues/62).
51− * When used with the UTF-8 encoding performance improvements
52− introduced in version 0.11.1.12 of the text package, this
53− release improves aeson's JSON encoding performance by 33%
54− relative to aeson 0.4.
56− As part of achieving this improvement, an API change was
57− necessary. The fromValue function in the
58− Data.Aeson.Encode module now uses the text package's
59− Builder type instead of the blaze-builder package's
64− * The new decode function complements the longstanding
65− encode function, and makes the API simpler.
67− * New examples make it easier to learn to use the package
68− (https://github.com/bos/aeson/tree/master/examples).
72− aeson's support for data-type generic programming makes it
73− possible to use JSON encodings of most data types without
74− writing any boilerplate instances.
76− Thanks to Bas Van Dijk, aeson now supports the two major
77− schemes for doing datatype-generic programming:
79− * the modern mechanism, built into GHC itself
80− (http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html)
82− * the older mechanism, based on SYB (aka "scrap your
85− The modern GHC-based generic mechanism is fast and terse: in
86− fact, its performance is generally comparable in performance
87− to hand-written and TH-derived ToJSON and FromJSON
88− instances. To see how to use GHC generics, refer to
91− The SYB-based generics support lives in Data.Aeson.Generic
92− and is provided mainly for users of GHC older than 7.2. SYB
93− is far slower (by about 10x) than the more modern generic
94− mechanism. To see how to use SYB generics, refer to
95− examples/GenericSYB.hs.
97− * We switched the intermediate representation of JSON objects
98− from Data.Map to Data.HashMap which has improved type
99− conversion performance.
101− * Instances of ToJSON and FromJSON for tuples are between 45%
102− and 70% faster than in 0.3.
104− * Evaluation control
106− This version of aeson makes explicit the decoupling between
107− *identifying* an element of a JSON document and *converting*
108− it to Haskell. See the Data.Aeson.Parser documentation for
111− The normal aeson decode function performs identification
112− strictly, but defers conversion until needed. This can
113− result in improved performance (e.g. if the results of some
114− conversions are never needed), but at a cost in increased
117− The new decode' function performs identification and
118− conversion immediately. This incurs an up-front cost in CPU
119− cycles, but reduces reduce memory consumption.