build-depends harmful (was RE: import resolution)

[Simon Marlow]

On 18 April 2005 21:18, S. Alexander Jacobson wrote:

> I just reread my prior post and realized that it was not entirely in
> english.  Trying again...
> 
> Module names in import statements refer to module specifications not
> module implementations.  e.g. if Prelude refers to a spec not an
> implementation, then use of any module that uses the Prelude must also
> refer to a spec rather than an implementation.
> 
> Module users select hardware platform, operating system, compiler,
> etc. They should also be selecting the best modules implementations
> for their context. Module packagers lack enough information about user
> context to do so.
> 
> The problem with build-depends and the Package Overlap Restriction is
> that they move decision making from module users to module packagers.
> Build-depends is far more egregious than POR and far more optional.

I think you misunderstand build-depends.  It allows the author of a
library to specify which implementations of a dependency are compatible
with the source code of the current package; i.e. which packages will
satisfy the dependency.

(I'd be happier if you'd call the Package Overlap Restriction the Module
Overlap Restriction, since it really has nothing to do with packages:
Haskell 98 contains this restriction).

> Packages should simply be collections of module implementations with
> meta-data about how/where those implementations are best used.
>
> Users should then select implementations from (Hackage) catalogs of
these
> (Cabal) packages as needed.
>
> Therefore, we need to remove build-depends tags from Cabal files (or
> change their semantics), and make Hackage a full catalog
> serving/replication protocol.

Removing build-depends would impose the restriction that a module can
never change its interface, ever.  Additionally, users are required to
choose between available implementations, whether they want to or not.

This appears to be the nub of the issue: I'm opposed to adding this
restriction.  

Perhaps you could elaborate on how you would implement versioning in
that scenario, and how we could add to or change existing interfaces?

Cheers,
	Simon