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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
