I disagree with Simon Marlow here. In practice I think Claus' definition of compatible is good enough:
Simon Marlow wrote: > Claus Reinke wrote: > >> - consider adding a new monad transformer to a monad transformer >> library, or a new regex variant to a regex library - surely the new >> package version can still provide for clients of the old version > > This case doesn't work - if you add *anything* to a library, I can write > a module that can tell the difference. So whether your new version is > compatible in practice depends on the client. > One can write such a module. But that is only a problem if the old client accidentally can tell the difference. As far as I can see, the only two things that can go wrong are name conflicts and new instances. New names can only cause compilation to fail, and this can be fixed by using a mix of (1) adding an explicit import list to the old import statement, or (2) adding/expanding a hiding list to the old import statement, or (3) using module qualified names to remove the collision Fixing this sort of compile error is easy; nearly simple enough for a regexp script. And the fix does not break using the client with the old library. Adding things to the namespace should not always force a new API version number. The new instances normally can do harm as they overlap/duplicate instances imported/defined elsewhere. So new instances of pre-existing classes should trigger new a API version number. <brown bag>I accidentally caused a new release of regex-base/regex-posix to drag along an instance which caused such a conflict. I rolled back that change.</brown bag> -- Chris _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe