Adding binary to the Haskell Platform

Don Stewart dons at galois.com
Wed Aug 5 17:24:09 EDT 2009


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.

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 :/

This is the tension between "blessed" (small set of perfectionist libs)
and "comprehensive" (large set of not-quite-perfect useful libs).

And I'm somewhat concerned we're only focusing on the blessedness --
things being perfect -- rather than the comprehensiveness : things being
useful and widely used.

Do we need a policy decision: 

    * will the Platform Steering Committee make inclusion conditional on API changes?

Is that something we want to do?  Maybe we just decide on a case-by-case
basis.

-- Don


More information about the Libraries mailing list