[Haskell-cafe] The instability of Haskell libraries

[Jason Dagit]

On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen <jgoerzen at complete.org>wrote:

>
> A one-character change.  Harmless?  No.  It entirely changes what the
> function does.  Virtually any existing user of that function will be
> entirely broken.  Of particular note, it caused significant breakage in the
> date/time handling functions in HDBC.
>
> Now, one might argue that the function was incorrectly specified to begin
> with.  But a change like this demands a new function; the original one ought
> to be commented with the situation.
>
> My second example was the addition of instances to time.  This broke code
> where the omitted instances were defined locally.  Worse, the version number
> was not bumped in a significant way to permit testing for the condition, and
> thus conditional compilation, via cabal.  See http://bit.ly/cBDj3Q for
> more on that one.
>

This is of course in part due to a strength of cabal (remember that
strengths and weaknesses tend to come together).  Cabal discourages testing
libraries/apis at configure time.  The result is that version numbers need
to encode this information.  We don't (yet), have a tool to help detect when
a change in version number is needed or what the next version should be.  We
leave this up to humans and it turns out, humans make mistakes :)

Even once we have an automatic tool to enforce/check the package version
policy, mistakes may still sneak in.  I would expect the 'T' in the time
format to be in this same category.**  More about that below.


>
> I don't have a magic bullet to suggest here.  But I would first say that
> this is a plea for people that commit to core libraries to please bear in
> mind the implications of what you're doing.  If you change a time format
> string, you're going to break code.  If you introduce new instances, you're
> going to break code.  These are not changes that should be made lightly, and
> if they must be made (I'd say there's a stronger case for the time instances
> than the s/ /T/ change), then the version number must be bumped
> significantly enough to be Cabal-testable.
>

While I haven't participated in the library proposal process myself, I was
under the impression that Haskell has a fairly rigorous process in place for
modifying the core libraries.  Is the above change too small to for that
process?  Did that process simply fail here?

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100423/1f45bf24/attachment.html