On 15 April 2005 23:45, 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.

No, a module name specifies a module, that's all. A Haskell program currently consists of a collection of modules, each with a distinct name. If the overlap restriction were lifted, a Haskell program would consist of a collection of modules, each of which is identified by a distinct (module name, package name) pair. This is what Simon is referring to in the comment above. You apparently want to impose a further restriction: that a module name identifies an interface. The same interface, for all time. That sounds like a pretty restrictive world to live in! We can't ever change the interface of a module without changing its name, which would lead to lots of weird module names and probably version numbers cluttering up the module namespace.

...

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.

If we lifed the module overlap restriction (what this discussion was about), then a program could contain multiple Ms, and therefore multiple M.Ts, which would be incompatible. [ rest of post deleted.. I'll answer the later version ] Cheers, Simon