RE: import resolution (was RE: exposed packages and cabal depends)
I've not been following the details of this thread, but I can say this: | PS In my last few posts I assumed you had rejected removing the | overlap restriction because that is what I interperted you to have | said e.g. here: | | We're not going to support this, at least for the forseeable future. | It's a pretty big change: every entity in the program becomes | parameterised by the package name as well as the module name, because | module names can overlap. Simon and I regard this as a shortcoming of Haskell, and of GHC in particular. Just because package A happens to use a module called Foo.Baz should not prevent package B from doing so. The Right Thing to do must be to regard the "full module name" as being the package name pre-pended to the module name. There is no difficulty in principle. But a) There are engineering considerations here. Notably, we are already concerned about the length of symbol names (in binaries, connected up by the linker), and this'd make them longer still. b) We worry about error messages like "cannot unify M.T with M.T" (meaning different M's!) c) We could probably do GHC, but what about Hugs and NHC?? d) It would be a fair amount of work, and there are plenty of competing things we'd like to do. Furthermore e) While this is the Right Thing, the workaround is easy: in package P, make your (internal) module names start "P.", to keep them out of other people's hair. (The fact that package names don't have the same lexical syntax as module names is a fly in this ointment.) I think that summarises the reasons why there has been no movement on this particular front, at least as I understand it. Simon
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
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
On Mon, 18 Apr 2005, S. Alexander Jacobson wrote:
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.
That implies that module names should have (possibly optional) version
numbers, because specifications change.
Tony.
--
f.a.n.finch
participants (3)
-
S. Alexander Jacobson -
Simon Peyton-Jones -
Tony Finch