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