Adding binary to the Haskell Platform

Ian Lynagh igloo at
Wed Aug 5 17:46:18 EDT 2009

On Wed, Aug 05, 2009 at 02:24:09PM -0700, Donald Bruce Stewart wrote:
> igloo:
> > On Wed, Aug 05, 2009 at 01:47:07PM -0700, Donald Bruce Stewart wrote:
> > > alexander.dunlap:
> > > > 
> > > > OK. Would it be worth creating an extensible exception (something like
> > > > BinaryDecodeError) for this then, instead of using the call to error?
> > > > That would at least make it less error-prone to catch.
> > > 
> > > I think that would be a good idea. Showing how to catch it in the
> > > documentation.
> > > 
> > > I'm wary of breaking the 70 packages that use Data.Binary for this,
> > > rather, add this as a list of API changes for the next major release.
> > 
> > If you're planning a change that you are worried would break users of
> > the package, wouldn't it be better to do it before putting it into the
> > platform?
> > 
> > Or have I misunderstood what you meant?
> So two things:
>     1. We can do API-breaking changes in the platform on major releases.
>     2. When new packages come in, I'm wary of breaking their APIs as
>         established prior to them being added, as then the platform
>         release that includes them is not usable as a platform for those
>         existing packages.

I don't understand how
    adding newapi in HPv2
is worse than 
    adding oldapi in HPv2
    replacing it with newapi in HPv3

Either way, when you put newapi in the HP there will be a period where
other packages need to catch up with the changes.

I'm not opposed to changing APIs in the platform, and if it would take a
long time to design, implement and test a planned API change then I
wouldn't see a problem with adding an oldapi in the mean time (assuming
oldapi is "good enough").

> Maybe 2 is not a valid concern. Maybe the HP inclusion is the time to
> break things. But maybe we won't then add popular packages -- because
> changing their APIs as requested would break too many things :/

I think we have to be willing to break things, or we will become
obsolete. There is a balance between stability and progress, of course.


More information about the Libraries mailing list