[Haskell-cafe] Re: Proposal: register a package asprovidingseveralAPI versions

Simon Marlow simonmarhaskell at gmail.com
Thu Oct 18 04:57:31 EDT 2007

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:


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).


More information about the Haskell-Cafe mailing list