Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))

[Simon Marlow]

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