Cabal vs Haskell [sic]
S. Alexander Jacobson
alex at alexjacobson.com
Wed Apr 20 17:18:17 EDT 2005
>> 1. It should require minimal work for a user to share an
>> 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.
> That's not true. Of course a single standalone pure haskell module or
> a set of simple modules can just sit in your source tree or elsewhere
> on the search path, just as they always have.
Neither Build-depends nor -package support finding a naked
implementation at an arbitrary location in the filesystem. Both only
recognize modules that have been packaged. -i complies with #1, but
it violates "the works over the Internet" requirement.
> Also framing this as a "Cabal vs. Haskell" discussion where you claim
> that your opinion is the True Haskell Way is both unfair and annoying.
If the names annoy you, please suggest alternatives. I think they are
descriptive of vastly different ways to understand a Haskell program.
Under Haskell, the module is the starting point for understanding a
program. Under Cabal, the Cabal file is the starting point for
understanding a program (e.g. the main-is tag). With Haskell, the
user select the modules to be used to resolve import statements.
With Cabal, the author makes the selection (e.g. the build-depends
tag). With Haskell, dependencies are between modules. With Cabal,
they are between packages.
You might have a good reason to favor one model or the other, but its
pretty clear that they are different.
> - Cabal doesn't require any changes or extensions to the Haskell
> language (it's not Cabal vs. Haskell!)
Yes it does! It requires that you understand Cabal to interpret a
Haskell program. In particular, as noted above, it specifies that you
can only reach modules through main-is tags in Cabal files. Further
it specifies that import statements in those modules have no meaning
independent of build-depends tags in those Cabal files.
> - The packaging system pre-dates Cabal. Cabal was layered on top of
> the packaging system, and a newer, more robust packaging system was
> designed and implemented in GHC in order to support more.
Ok, I am not objecting to having a package system per se (see my prior
post). I am objecting to having a package system with a build-depends
tag that points to other packages and I think that Cabal is the name
for such package system.
> At this point, I hope no one is drawing information about Cabal from
> your posts.
To be precise, I am using Cabal to describe a program model not the
details of a particular implementation of that model. I have no doubt
that Cabal is a superb *implementations*. Now, although I am
concerned is that it is a superb implementation of the wrong model, I
am also hopeful that we will be able to reuse much of it when we shift
to a better one.
In any case, my goal in this discussion is to spur better
understanding of the model. Please do not take any of my comments as
a disparagement of any implementation.
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries