We seem to have several interlocking decisions to make about *aeson* and *dlist* in the platform: *Background:* *let me know if I got any of this wrong* - There is clear agreement to have *aeson* in the platform. - *aeson* 0.6.2.1 would require *dlist* & *blaze-builder* to be added. - There is a patch to *aeson*, already in head, that makes *aeson* use the builder in *bytestring*, and drop the dependency on *blaze-builder*. This is good, as a *bytestring* in GHC 7.8 will make *blaze-builder*obsolete. - *aeson* head uses a new Scientific type for arbitrary precision floating point. This will break users of the Number constructor of the Value type. However, it is believed that most users are probably using existing functions to parse to an from standard numeric types when needed, and those continue to work. Unclear how much impact this will have. Also, Scientific could be in it's own package (which would need to be added to the platform), or simply exposed from *aeson*. - *dlist* is stable, but could use some love - which was lovingly offered, and we could have a bump which adds some useful typeclass instances. - It was noted that *dlist* could be replaced by Endo, or explicit use of simple types. There didn't seem to be much support for the idea of altering *aeson* to do so. *Options for aeson:* 1. skip it in this release 2. include *aeson* 0.6.2.1 - requiring both *dlist* and *blaze-builder* 3. include *aeson* 0.6.2.x, a version with the patch that uses *bytestring*'s builder, and so require only *dlist* 4. include *aeson* 0.7.0.0 - requiring *dlist* and possibly *scientific* *Options for dlist, if required by the aeson choice, or because we now like it anyway:* 1. include *dlist* 0.5 2. include *dlist* 0.6, with new typeclass instances added *Options for scientific, if required by the aeson choice:* 1. include Scientific type in *aeson* 2. include a new *scientific* pacakge *Discussion:* I think the best option, if we are ready to embrace aeson, is jump in with both feet: aeson 0.7.0.0, & dlist 0.6. Leaving the issue of is scientific ready to be included as it's own package, or should it just be exported by aeson for now. Thoughts? — Mark