Add binary and/or cereal to the Haskell Platform - Libraries - Haskell.org

newer
Signature of Control.Monad when...

Add binary and/or cereal to the Haskell Platform

older
addForeignPtrFinalizer -...

Yitzchak Gale

22 Aug 2012 22 Aug '12

8:40 a.m.

I see that several years ago a proposal page was prepared for adding the binary package to the Haskell Platform, but it was never actually submitted as a proposal. http://trac.haskell.org/haskell-platform/wiki/Proposals/binary I think the reason it was not submitted was that things were in flux at that time regarding the binary and cereal packages. Now the situation has settled down. I think one or both of those packages ought to be added to the platform. Any opinions? Thanks, Yitz

Reply

Sign in to reply online Use email software

Show replies by date

Johan Tibell

22 Aug 22 Aug

3:05 p.m.

Hi all, On Wed, Aug 22, 2012 at 1:40 AM, Yitzchak Gale wrote:

I see that several years ago a proposal page was prepared for adding the binary package to the Haskell Platform, but it was never actually submitted as a proposal.

http://trac.haskell.org/haskell-platform/wiki/Proposals/binary

I think the reason it was not submitted was that things were in flux at that time regarding the binary and cereal packages.

Now the situation has settled down. I think one or both of those packages ought to be added to the platform. Any opinions?

As I've mentioned before [1] I think binary and cereal should be merged. They are almost identical and both the strict (cereal) and lazy (binary) runGet interfaces can coexist in the same API, implemented on top of runGetPartial. The only remaining issue I'm aware of is that Lennart tried implementing the current binary API using continuations and it was a bit tricky to maintain performance. Furthermore, I really think the Put and Get modules should be split, which implement encoding/decoding of base types in standardized encodings, should be split from the Binary/Cereal module, which implement a very specific and non-standardized (but still useful) format. Not not break any old code I suggest that the binary/cereal package will re-export this split off API (e.g. a new binary-encodings package). 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html -- Johan

Reply

Sign in to reply online Use email software

Yitzchak Gale

3:20 p.m.

Hi Johan, Johan Tibell wrote:

As I've mentioned before [1] I think binary and cereal should be merged.... [other proposed API improvements] 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html

Yes, those are great ideas. The thing is, nobody (myself included of course) has done anything about it for almost two years. Right now, binary and cereal are what they are. These are important packages that are popular dependencies. I observe empirically that their APIs are extremely stable. Unless there is new evidence that someone will work on them in the very near future and change the APIs significantly, I think they should go into the platform the way they are now. Or at least one of the two. I'd like to hear other opinions on that, though. Better yet - here's an easy chance for someone to step up, be a hero, and become famous. Thanks, Yitz

Reply

Sign in to reply online Use email software

Johan Tibell

4:29 p.m.

On Wed, Aug 22, 2012 at 8:20 AM, Yitzchak Gale wrote:

Hi Johan,

Johan Tibell wrote:

...
As I've mentioned before [1] I think binary and cereal should be merged.... [other proposed API improvements] 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html

Yes, those are great ideas. The thing is, nobody (myself included of course) has done anything about it for almost two years. Right now, binary and cereal are what they are. These are important packages that are popular dependencies. I observe empirically that their APIs are extremely stable. Unless there is new evidence that someone will work on them in the very near future and change the APIs significantly, I think they should go into the platform the way they are now. Or at least one of the two.

I agree with this sentiment. My current thinking is that perhaps it's better to leave both out. I don't feel too strongly about it though. If binary went in we might convince Lennart to finish and release his "cps" branch which should give binary incremental input capabilities. -- Johan

Reply

Sign in to reply online Use email software

Don Stewart

5:26 p.m.

I'd say put the strict bs (cereal) and lazy bs (binary) in. On Wednesday, August 22, 2012, Johan Tibell wrote:

On Wed, Aug 22, 2012 at 8:20 AM, Yitzchak Gale javascript:;> wrote:

...
Hi Johan,

Johan Tibell wrote:

...
As I've mentioned before [1] I think binary and cereal should be merged.... [other proposed API improvements] 1. http://blog.johantibell.com/2011/01/merging-binary-and-cereal.html

Yes, those are great ideas. The thing is, nobody (myself included of course) has done anything about it for almost two years. Right now, binary and cereal are what they are. These are important packages that are popular dependencies. I observe empirically that their APIs are extremely stable. Unless there is new evidence that someone will work on them in the very near future and change the APIs significantly, I think they should go into the platform the way they are now. Or at least one of the two.

I agree with this sentiment. My current thinking is that perhaps it's better to leave both out. I don't feel too strongly about it though. If binary went in we might convince Lennart to finish and release his "cps" branch which should give binary incremental input capabilities.

-- Johan

_______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Bryan O'Sullivan

5:28 p.m.

On Wed, Aug 22, 2012 at 9:29 AM, Johan Tibell wrote:

My current thinking is that perhaps it's better to leave both out.

For me, a disincentive to accepting binary is that it doesn't provide a way for a Get to fail. I'd be more in favour of cereal for that reason.

Reply

Sign in to reply online Use email software

Johan Tibell

5:33 p.m.

On Wed, Aug 22, 2012 at 10:28 AM, Bryan O'Sullivan wrote:

On Wed, Aug 22, 2012 at 9:29 AM, Johan Tibell wrote:

...
My current thinking is that perhaps it's better to leave both out.

For me, a disincentive to accepting binary is that it doesn't provide a way for a Get to fail. I'd be more in favour of cereal for that reason.

I switched my latest in progress package to cereal for this reason, and because I needed to incrementally supply data while parsing. -- Johan

Reply

Sign in to reply online Use email software

Trevor Elliott

8:53 p.m.

This was the motivation for the initial work on cereal. I'd be happy to see cereal make it into the HP, and I do believe that it provides a different feature set than binary, but I worry that it's reaching feature parity with attoparsec. I'm not sure what to do in the long run for this, as the two are used in fairly different ways. Maybe cereal could eventually become some sort of presentation of attoparsec and one of the builder packages? --trevor On Wed 22 Aug 2012 10:33:17 AM PDT, Johan Tibell wrote:

On Wed, Aug 22, 2012 at 10:28 AM, Bryan O'Sullivan wrote:

...
On Wed, Aug 22, 2012 at 9:29 AM, Johan Tibell wrote:

...
My current thinking is that perhaps it's better to leave both out.

For me, a disincentive to accepting binary is that it doesn't provide a way for a Get to fail. I'd be more in favour of cereal for that reason.

I switched my latest in progress package to cereal for this reason, and because I needed to incrementally supply data while parsing.

-- Johan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Johan Tibell

9:19 p.m.

On Wed, Aug 22, 2012 at 1:53 PM, Trevor Elliott wrote:

This was the motivation for the initial work on cereal. I'd be happy to see cereal make it into the HP, and I do believe that it provides a different feature set than binary, but I worry that it's reaching feature parity with attoparsec. I'm not sure what to do in the long run for this, as the two are used in fairly different ways. Maybe cereal could eventually become some sort of presentation of attoparsec and one of the builder packages?

I think the builder should eventually end up being a thin wrapper around the new builder we're releasing in the next bytestring release (based on blaze-builder).

Reply

Sign in to reply online Use email software

4709

Age (days ago)

4709

Last active (days ago)

Download

8 comments

5 participants

tags

participants (5)

Bryan O'Sullivan
Don Stewart
Johan Tibell
Trevor Elliott
Yitzchak Gale