2013.4.0.0 proposal

[Bas van Dijk]

On 13 Nov 2013 20:33, "Mark Lentczner" <mark.lentczner at gmail.com> wrote:
>
> I'd like to better understand the backwards compatibility of these
changes, and this new major bump of aeson:

My idea for the new major release aeson-0.7 was that it would be included
in the next HP and introduce breaking changes but that it would
significantly stabilize after this. I would prefer this over first
including and old release and then later including a breaking release since
I would like the HP to be as stable as possible.

> On Mon, Nov 11, 2013 at 2:07 AM, Bas van Dijk <v.dijk.bas at gmail.com>
wrote:
>>
>> Note that I removed the blaze-builder requirement from aeson-HEAD (it
>> now uses the Builder from bytestring with a fallback to blaze-builder
>> when configured with -fblaze-builder).
>
>
> Which we'd have to do for this HP, as the bytestring package is 0.10.0.2
from the GHC release. Hence, the blaze-builder requirement would still be
there.

It seems bytestring-0.10.0.2 provides a Builder:

http://hackage.haskell.org/package/bytestring-0.10.0.2

>>
>> I think we're pretty close to a release of aeson-0.7.0.0. It would be
>> great to have this version in the HP since:
>
>
> I'm concerned about timing. In particular, how long should a new major
version bump release be out before one is confident that it won't need a
minor rev. (0.7.0.1) soon?
>
>>
>> * It includes an important bug fix for the eitherDecodeStrict functions
>
>
> Well, that seems good. Could that get back ported on top of 0.6.2.1 if we
decided to not do a major bump this time?

That won't be difficult.

>>
>>  * It has support for arbitrary precision floating point numbers (as
>>
>> required by the JSON spec) through the Scientific type.
>
>
> Well, one can argue if that is what the spec says - but in practice, JSON
libraries in other systems don't use arbitrary precision floating point
(nor does any JavaScript implementation that I know of).

True. However, users also might want to send arbitrary precision numbers as
JSON between two Haskell systems using aeson.

Also the Scientific type proved to be more efficient to parse.

> Those issues aside, how does the API evolve? What is the plan for
introducing this functionality without breaking existing aeson relying
code? aeson's Number constructor points to Number from attoparsec which has
only two constructors: I Integer and D Double. Wouldn't introducing a
third, or replacing D, break existing uses of aeson?

aeson-0.7 will break code that is directly constructing or analyzing the
Number type from the Number constructor from the Value type since that will
change to the Scientific number type.

I expect that there isn't that many code like that since for decoding or
encoding directly to standard numeric types users are probably using the
provided FromJSON and ToJSON instances which will keep working as they were.

For users that do need to use the Number constructor from the Value type
they can still use the (deprecated) withNumber function for parsing. For
construction I expect most of these users to use the standard numeric
conversion functions like fromInteger, fromIntegral or realToFrac which
should work unmodified for Scientific values.

>> * It removes the ByteString instances since JSON doesn't have support
>> for binary data (this was brought up during the HP inclusion
>> discussion).
>
>
> Do we have any usage stats to know if any code uses this show instance?

No we don't and I agree this would be useful to have but probably hard the
obtain.

> Again, trying to avoid breaking compiling code. Were deprecation notices
added to the package at some point?

I don't think you can add deprecation pragma's to instances which is
unfortunate.

Thanks for doing this due diligence Mark!

Bas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131113/e1987b89/attachment.html>