aeson and dlist in HP 2013.4.0.0

[Mark Lentczner]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20131117/15009d05/attachment.htm>