On Wed, 20 Apr 2005, Simon Marlow wrote:

Not at all - the definition of a Haskell program is still a collection of modules with distinct names. If we were to "lift the overlap restriction" then the definition would change to a collection of modules with distinct (package name, module name) pairs.

Yes, I understand this and oppose it. Packages should just be encapsulations of module implementations; they should have no functional signficance. Making package names part of module names endows them with functional significance, adding fragility and rigidity without providing any compensating values. Fragility Changes in code should be as local as possible. If package names are part of module names than a change to any module in any package that is part of a program can require changes to every other package in that program (to update package names). If packages simply encapsulate module implementations, then only modules that relied on the old interface need be changed. Rigidity Users should be able to select module implementations most appropriate for their contexts. If package names are part of module names, they can't do that. If packages are simply encapsulations of various module implementations then they can. (e.g. one package supplies a general purpose version of module M, while another supplies a version that takes special advantage of some feature of GHC 6.2, while another is optimized for some obscure CPU. The user should be able to select the package that is right for him/her). Complexity Note, I don't know what the user interface to adding package names to import statements would be, but I strongly suspect that it will be harder to understand than the current module names are just functional model. Lastly, I think you proposal to add package naes to the source is seriously at odds with your commment from earlier: Also, the Haskell module hierarchy is supposed to reflect functionality, whereas package names are purely administrative. This is a reason for not including package names in source code. http://www.haskell.org//pipermail/libraries/2005-April/003513.html I think the earlier point made much more sense. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Wed, 20 Apr 2005, Simon Marlow wrote:

On 20 April 2005 02:00, S. Alexander Jacobson wrote:

...

You appear be proposing to change the definition of a Haskell program from a set of Haskell modules connected by import to a set of Cabal packages connected by build-depends.

Not at all - the definition of a Haskell program is still a collection of modules with distinct names. If we were to "lift the overlap restriction" then the definition would change to a collection of modules with distinct (package name, module name) pairs. Two changes are required:

- define module name as (package name, module name) pair

- in the context of each module's source, there is a mapping from module name to package name that is used to resolve an import.

the definition doesn't require Cabal, or build-depends.

Given that this model doesn't rely on Cabal or build-depends, I'm afraid I don't understand the rest of your post. I think you may have misunderstood what the module overlap restriction is.

...

== Lifting The Overlap Restriction ==

The Haskell model is much simpler for the user and sacrifices little expressive power.

Under the Haskell model, M.T means the same thing in every module and lifting the overlap restriction means programs just have a lookup table mapping module names to module locations; resolution follows simply and directly without worrying about package structure.

If programs are still collections of modules with distinct names, then the module overlap restriction is still in place.

Perhaps you could define some terms more precisely, to avoid confusion: for example things like "module location", and what you understand by "overlap restriction".

Cheers, Simon