On 24/04/2010, at 19:25, Ivan Lazar Miljenovic wrote: > Roman Leshchinskiy <r...@cse.unsw.edu.au> writes: >> John Goerzen gave one in the very first post of this thread: the fix >> to old-locale which didn't change any types but apparently changed the >> behaviour of a function quite drastically. Another example would be a >> change to the Ord instances for Float and Double which would have >> compare raise an exception on NaNs as discussed in a different thread >> on this list. Another one, which is admittedly silly but demonstrates >> my point, would be changing the implementation of map to >> >> map _ _ = [] >> >> In general, any significant tightening/changing of preconditions and >> loosening/changing of postconditions would qualify. > > OK, fair enough, I see how these can be considered changing the API. > Thing is, whilst it would be possible in general to have a tool that > determines if the API has changed based upon type signatures, etc. how > would you go about automating the test for detecting if the "intention" > of a function changes in this manner?
I have no idea. However, just requiring the Platform packages to provide tests for the exposed functionality and to consider those when changing version numbers would be a big step forward in my opinion. *Any* notion of pre/postconditions as part of the interface is better than none at all. BTW, the versioning policy doesn't seem to even mention semantics. Perhaps we could add some text to the effect that it is a good idea to bump the version number if the semantics changes sufficiently even if the types don't? Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
