Cabal vs Haskell [sic]

[Isaac Jones]

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

> On Fri, 22 Apr 2005, Simon Peyton-Jones wrote:
>> Bottom line: the current story is pretty defensible.  I'm not sure that
>> keeping names unique by implicitly using package-ids is worth the
>> bother.
>
> If the current Haskell story is that module names are top-level then
> it is incompatible with the current Cabal story.  The current Cabal
> story is that module names are implicitly qualified by
> package-ids. Cabal's build-depends tag says that some set of package
> names are required to interpret enclosed import declarations.  In
> other words, that the import declarations are themselves insufficient
> to identify the external modules required to interpret the enclosed
> modules.

This is the case in every language I know of, except perhaps for Java
which requires that you prefix your organizational name to your
modules.  In fact we could do that in Haskell without changing
anything.

> I strongly prefer the current Haskell story to the current Cabal story
> for reasons enumerated at length in this thread*.  

Once again, the current cabal story is not different from the current
Haskell story.  Please stop saying that.  Cabal is layered on Haskell.

Cabal "changes" the interpretation of a Haskell module only in the
sense that Make changes the interpretation of a Haskell or C program
or that "-i" changes the interpretation of a Haskell or C program.
This is obvious, and I agree with it, but the way you keep phrasing it
makes me wonder if you understand this.

(snip)
> * Quick recap of arguments against Cabal:
>
>    * namespace issues shouldn't be mixed with physical packaging issues
>    * dev tools operate on source files/directories not packages
>    * Cabal fragility with respect to changes in build-depends tag
>    * Cabal fragility with respect to changes in modules of other packages
>    * incompatibility between unqualified imports and Cabal versioning

These are too vague to respond to (they have already been responded
to).  But I want to point out that no matter what system you use, if
the modules that my module depends on change in a bad way, then my
module will break.  The only way around this is good software
engineering.


peace,

  isaac