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

[S. Alexander Jacobson]

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
>