Cabal vs Haskell [sic]

Isaac Jones ijones at
Wed Apr 20 17:40:14 EDT 2005

"S. Alexander Jacobson" <alex at> writes:

>>>    1. It should require minimal work for a user to share an
>>>       implementation.
>>> 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.

If build-depends or -package somehow took away the "-i" option, then
it might be true that "they both force users to create packages even
to share standalone pure haskell modules." But that's not the case.

You are free to not use -package and you are free to not use
build-depends and only use "-i".  Nothing is forced on anyone.  All
you are saying is that "-package refers to a package."

>> 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.  

How about the "Cabal / HC-PKG approach vs the Alex Jacobson approach"?
It's much less loaded.

> 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).

No.  Under Cabal, the .cabal file is the starting point for
understanding a package.  The source code is still plain-old Haskell.

>> - 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.  

Cabal is layered on top of the language.  It doesn't change the

> 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.

I'm not taking it like that.  I'm trying to help clarify what I think
are mischaracterizations on your part.



More information about the Libraries mailing list