Cabal vs Haskell [sic]
ijones at syntaxpolice.org
Wed Apr 20 16:06:37 EDT 2005
"S. Alexander Jacobson" <alex at alexjacobson.com> writes:
> 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
> 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.
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.
A couple of point of clarity for anyone following this discussion:
- Cabal doesn't require any changes or extensions to the Haskell
language (it's not Cabal vs. Haskell!)
- 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.
At this point, I hope no one is drawing information about Cabal from
More information about the Libraries