Hi Alex, I'm going to take a break from this discussion for a while. If I responded to your previous message, I feel I'd be repeating a lot of things I've already said in this thread, and not really making any progress. That's not to say there isn't progress to be made. I suggest that if you want to propose a change to Haskell and/or Cabal, you write it down as precisely as possible and send it to the list. If possible, separate proposals into smaller parts - separate changes to the Haskell definition from changes to the package system and changes to Cabal. Cheers, Simon On 20 April 2005 19:43, S. Alexander Jacobson wrote:

Simon,

Right now, a module name in an import declaration identifies a module specification, a module name in a module declaration identifies an implementation, and some "external mechanism" resolves specifications to implementations. The big issue on the table here is what exactly this "external mechanism" should be. I'll suggest some requirements:

1. It should require minimal work for a user to share an implementation.

2. It should work with and accross the Internet.

3. It should allow arbitrtary sets of implementations to be delivered together as needed.

4. It should be able to work without substantial user intervention.

5. Module users rather than module authors should select how imported module names are resolved to implementations.

6. Interface changes should be local to users of those interfaces.

7. It needs to handle foreign implementations (FFI)

Unfortunately, our existing module resolver mechanisms are severely inadequate here. Build-depends and -package both violate #1 because they both force users to create packages even to share standalone pure haskell modules. The fact that module/package names can't currently be resolved to URLs means both also violate #2 and #4. That packages can contain at most one implementation of any module violates #3 and #5 (and it is just a file format problem!). That package build/install processes can modify overall system state violates #4. Build-depends MAJORLY violates #5 and #6. On the plus side, they both handle #7.

I'd like Haskell to have a module resolver mechanism that fulfills our requirements and does not have these problems.

-Alex-

______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

On Wed, 20 Apr 2005, Simon Marlow wrote:

...

On 20 April 2005 11:56, S. Alexander Jacobson wrote:

...

Lastly, I think you proposal to add package naes to the source is seriously at odds with your commment from earlier:

I'm not proposing to add package names to source code.

The rest of your post was based on this misconception, so I won't answer it.

I realise my description of the idea wasn't as complete as it could have been. I'll try to describe the idea more precisely. (note this isn't a proposal as such).

- source code continues to use module *names* only.

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

- in the context of each module's source, there is assumed to be a mapping from module name to module identifier established by some external mechanism.

The "external mechanism" referred to here could be GHC's -package flags, or Cabal's build-depends, for example. For the purposes of the language definition, it doesn't matter.

...

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

My position on this has (still) not changed!

Cheers, Simon