[Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions

[Claus Reinke]

> These two cases could be solved by re-exports, no extra mechanism is required.

yes, good support for re-export would be nice to have. the
reason it has so many applications is that it is a way to explain
connections between providers, apis, and clients to the package
manager.
 
>> - 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.

of course you can. but then you're writing new code. my concern
was with old code that was written to the old api and that would
still work with an extended api. i was suggesting a warning if code
was compiled against an older api in any case. 

you're right, if you can design new code that will notice the 
additions, then there's a chance that old code might stumble 
over them. if that breaks compilation, the programmer would 
see the error message preceded by an old-api warning, so
it should be obvious what to do - either adapt the package
to the new api, or make sure that it cannot see anything but
the old api.

unfortunately, packages are specified entirely at the level of
module names. as far as the package manager is concerned,
anything that exposes the same modules is "compatible", the
breakage comes when the package manager calls the compiler.
so we can't say that the old package should import only
specific items from the old api, because that api is specified
only in the haddock comments, not in any package spec.

and then there are the nasty cases, where adding instances
might change compilation results without breaking compilation.

>> - consider various packages providing different implementations
>>    of an api, say edison's - surely any of the implementations will
>>    do for clients who depend only on the api, not on specifics
> 
> Yes, and in this case we should have another package that just 
> re-exports one of the underlying packages.

what you're suggesting is to make an intermediate package act
as an api spec: instead of clients depending directly on providers,
they depend on the api spec package, and the api spec package
"knows" which providers can implement it.

> You seem to want to add another layer of granularity in addition to 
> packages, and I think that would be unnecessary complexity.

well, what is ever necessary?-) but i thought the discussion
had already made clear that cabal specs do not provide 
sufficient information to 

    - guarantee package compatibility
    - delimit usage of apis in clients
    - find providers implementing apis
    - keep old packages working with new providers,
        instead of preserving/packaging all packages forever

which means that there's more need to update cabal specs
and to use other means (central repo at hackage with 
autobuild reports, etc) to ensure that everything keeps 
working. that means more work than necessary, more
breakage and less safety than desirable (for a formal
take on package safety, refer to Standard ML's system,
with structures, functors, and interfaces as a statically
typed functional package and module composition 
language; just add an rcs for package versions).

claus