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. 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. -Alex- PS I hope this finally makes sense.... ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Fri, 15 Apr 2005, S. Alexander Jacobson wrote:
On Thu, 14 Apr 2005, Simon Peyton-Jones wrote:
The Right Thing to do must be to regard the "full module name" as being the package name pre-pended to the module name.
I don't think that is right. As far as I understand, module names in import statements identify specifications not implementations. Otherwise, it would be incorrect for different compilers to implement the Prelude differently. Resolution of imported module names to meanings or specifications is fundamentally different from resolution of module names to implementations. The former is the domain of the programmer and the later is the domain of the compiler/interpreter.
b) We worry about error messages like "cannot unify M.T with M.T" (meaning different M's!)
I think the Haskell report is pretty clear that M.T always means M.T. So, I interpret this as an error in the status quo that can result from multiple packages requiring conflicting implementations of M.
The core problem here is that packages should not be *requiring* implementations of anything. They should only be providing them.
Under the package overlap restriction, containment is identical with requirement. So the pacakge overlap restriction is a minor instance of this problem A much more major instance results from putting build-depends tags in cabal files. Instead of being unable to use package A with package B if both *contain* an implementation of Foo.Baz, build-depends means that you are unable to use package A with package B if both *require* an implementation of Foo.Baz. The likelihood of conflict therefore rises considerably.
What we really need here is Hackage on steroids; a way for compilers/interpreters to look up module names in shared directories/name-servers in order to obtain packaged implementations that are compatible with the target platform (perhaps via a compile) and with each other (if the package overlap restriction survives).
I know we've been going back and forth on this discussion for a while and my position has changed some. I want to thank you for your patience. I hope this post finally makese some sense.
-Alex-
* I think we should also have a somewhat more explicit system for allocating module namespace, but that is a whole separate discussion whose resolution is dependent on this one.
PS Though I didn't quote them, I think this post also addresses the concerns expressed in David Roundy, Wolfgang Thaller, Simon Marlow's and Isaac Jones. If not, please advice.
______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries