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

Simon Peyton-Jones simonpj at microsoft.com
Thu Apr 14 04:13:06 EDT 2005


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  


More information about the Libraries mailing list