Cabal vs Haskell (was RE: build-depends harmful (was RE: import
S. Alexander Jacobson
alex at alexjacobson.com
Wed Apr 20 14:42:30 EDT 2005
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
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
> 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