Joachim Breitner wrote:

Felipe Almeida Lessa wrote:

...

Given that you are following the PVP, I would put the following constraint:

Build-depends: foo >= 0.1 && < 0.2

However, if someone with an older version of foo installed on their system tried to install my package, they would get a type error, since I haven't put a "Typeable a =>" context on my bar.

would you? I think you would use foo >= 0.1.3 && < 0.2, because 0.1.3 is allowed to have API additions that are not in 0.1.2, so if you develop your library against 0.1.3, there is no guarantee that foo was not empty in 0.1.2.

Under this interpretation, removing a constraint should be equivalent to an API addition, hence rule 2 on http://www.haskell.org/haskellwiki/Package_versioning_policy#Version_numbers ought to apply.

I like that point of view. In a sense, generalizing a type is literally equivalent to adding a new function to the API which can be used in new contexts. The only difference is that the new function has the same name as the old one. It's not entirely safe to generalize a type, though, due to issues with type classes and ambiguity. For instance, the generalization read :: Read a => String -> a - showDouble :: Double -> String + showDouble :: Floating a => a -> String will break the program foo :: String -> String foo = showDouble . read That said, is it true that *removing* a class constraint will never cause ambiguities? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com