Cabal vs Haskell [sic]

[Isaac Jones]

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

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

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

peace,

  isaac