Simon, You appear be proposing to change the definition of a Haskell program from a set of Haskell modules connected by import to a set of Cabal packages connected by build-depends. I am going to call the former the Haskell model and the later the Cabal model. In this mesage I hope to convince you that the Haskell model is simpler for the user to understand in the context of package overlap, more robust with respect to change, and more adaptable to various usage contexts. I hope to convince you that the Haskel model is stricly superior to that of Cabal. == Lifting The Overlap Restriction == The Haskell model is much simpler for the user and sacrifices little expressive power. Under the Haskell model, M.T means the same thing in every module and lifting the overlap restriction means programs just have a lookup table mapping module names to module locations; resolution follows simply and directly without worrying about package structure. Under the Cabal model, M.T can mean different things in different modules and lifting the overlap restriction means programs must have a lookup table mapping package name/module name pairs to module locations. Resolution in this case is complex. It depends on both the other contents of the package supplying the importing module AND the build-depends tag of that module. == Handling Change/Versioning == Haskell model programs are MUCH more robust with respect to change than programs under the Cabal model. Under the Haskell model, only module interface changes can break a program. However, module interface changes that actually break a program are relatively rare because most changes simply involve adding new functions and the remainder can be managed reasonably using the *Deprecated* tag (no need for an elaborate versioning scheme). Under the Cabal model, module interface changes can also break a program, but so can changes in build-depends tags. The big problem is that changes in build-depends tags are VERY LIKELY to break programs. For example, suppose package P1 is modified to build-depend on a new version of package P2. Now every other package that also uses P2 must also be updated. And if the new version of P2 build-depends on a new verion of P3, now every other package that uses P3 must also be updated, etc, etc. Catastrophe! == Adaptability == Haskell model programs can better adapt to usage context than programs using the Cabal model. For example, suppose someone produces an implementation of module M that works especially well on a particular platform/OS or fulfills a particular memory/cpu tradeoff. Under the Haskell model, a user would be free to use such in implementation in any program that uses module M. Under the Cabal model, the user could use this module only in programs that build-depends on versions of packages that know to provide this implementation in this particular context. == Hackage == Haskell Hackage is a mapping from module names to package locations. Cabal Hackage is a mapping from package names to package locations. == Conclusion == You said earlier that module names should be functional and package names should be administrative. To me, that is a clear endorsement of the Haskell model. However, in this discussion you and SPJ appear to have drifted away from it. I hope I have convinced you to stick with Haskell. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Tue, 19 Apr 2005, Simon Marlow wrote:

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