[Haskell-cafe] Package versioning policy - Harmless type changes?

[Heinrich Apfelmus]

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