Cabal vs Haskell [sic]

S. Alexander Jacobson alex at
Wed Apr 27 21:58:39 EDT 2005

On Tue, 26 Apr 2005, David Roundy wrote:
> On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:
>>   Me: My fundamental point here is that the meaning of code shouldn't
>>   change depending on the location where it is interpreted. [...]
> But that has *never* been true.  The meaning of import Data.List has always
> depended on which version of which compiler you've got.

On Tue, 26 Apr 2005, Benjamin Franksen wrote:
> BTW, I know of no programming language in which module import clauses have a
> global (world wide) meaning. Resolution of module names in import clauses to
> actual source or object code is always system or compiler dependent.

Ok, let me be more explicit.  The *intensional* meaning of code 
shouldn't change depending on the location where it is interpreted.
e.g. Data.List.sort should always mean "sorting a list"

The *extensional* meaning of the code, the implementation, should be 
at complete disgresion of the user.
e.g. whether to implement Data.List.sort as quicksort or insertion 
sort and with which compiler and on which platform, etc...

Note that one and only one implementation of any type/function is 
allowed per program. So the mapping from meaning to implementation 
must be program global rather than local to a package/module or you 
risk incompatibilities.

My objection to Cabal is that it either makes the meanings of 
haskell modules context relative OR it takes implementation choice 
away from the user/makes it package local (depending on whether 
build-depends is about meaning or implementation).

Isaac proposes that we should modify build-depends to offer a choice 
from a finite set of implementations.  But, my point is that the user 
should have infinite choice in implementation and that the decision 
making cannot be package local.  The whole build-depends semantic just 
doesn't belong in Cabal.

Effectively, we need less Cabal and more Hackage.  Compilers should 
have access to directory servers that resolve module names to sets of 
URLs of module implementations.  The compiler will select one 
implementation per module to be shared by all modules that import it.

A module implementation make either take the form of Haskell source or 
a package containing exposing the module.


S. Alexander Jacobson tel:917-770-6565

More information about the Libraries mailing list