Proposal: register a package as providing several API versions

[apfelmus]

Simon Marlow wrote:
> The proposed policy, for the sake of completeness is: x.y where:
> 
>   x changes ==> API changed
>   x constant but y changes ==> API extended only
>   x and y constant ==> API is identical
> [..]
> dependencies must specify a single x.y API version, or a range of 
> versions with an upper bound.

What about x == 0? I mean, the intention of 0 is that 0.1, 0.2 and so on 
may well overthrow the API. But that's a bikeshed issue.

ChrisK wrote:
> The above declaratively expresses that libcurl-3.3.0 provides the version 3 API
> and the version 2 API.

Good idea.

In the end, both proposals are based on the same observation: the 
dependency knows best which of its versions are compatible and which 
aren't. It's *not* a responsibility of the dependent package to know 
that. It only has to know one particular version it compiles against.

So, it would just specify "I do compile with foobar 1.2" and let foobar 
1.3 decide whether it's compatible with 1.2 or not. Given Simon's 
proposed policy, the answer would be "yes", if it were not for possible 
name clashes:

> However, there's an important difference between shared-library
> linking and Haskell: in Haskell, a superset of an API is not
> backwards-compatible, because it has the potential to cause new name clashes.

Solution? explicit imports? explicit module signatures with subtyping? 
implicit signature conversion foobar 1.3 -> foobar 1.2 on the package level?

Regards,
apfelmus