On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen
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