Cabal vs Haskell [sic]
S. Alexander Jacobson
alex at alexjacobson.com
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.
-Alex-
______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries
mailing list