ChrisK wrote:
I disagree with Simon Marlow here. In practice I think Claus' definition of compatible is good enough:
I don't think you're disagreeing with me :-) In fact, you agreed that extending an API can break a 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.
Yes the errors can be fixed, but it's too late - the client already failed to compile out of the box against the specified dependencies. New instances are ruled out in the definition of an extended API in the version policy proposal, incedentally: http://haskell.org/haskellwiki/Package_versioning_policy And I agree with you that name clashes are rare, which is why that page recommends specifying dependencies that are insensitive to changes in the minor version number (i.e. API extensions). But that still leaves the possibility of breakage if the client isn't using import lists, and Claus argued for a system with no uncertainty. So if you want no uncertainty in your dependencies, you either have to (a) not depend on API versions (including minor versions) that you haven't tested, or (b) use explicit import lists and allow minor version changes only. Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). Cheers, Simon