[Haskell-cafe] Package versioning policy - Harmless type changes?
apfelmus at quantentunnel.de
Fri Sep 23 09:18:45 CEST 2011
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
More information about the Haskell-Cafe