import resolution (was RE: exposed packages and cabal depends)

S. Alexander Jacobson alex at alexjacobson.com
Fri Apr 15 18:45:27 EDT 2005


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


More information about the Libraries mailing list