Cabal vs Haskell (was RE: build-depends harmful (was RE: import
simonmar at microsoft.com
Thu Apr 21 04:55:11 EDT 2005
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
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.
On 20 April 2005 19:43, S. Alexander Jacobson wrote:
> 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
> 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
> 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.
> 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.
>> My position on this has (still) not changed!
More information about the Libraries