Cabal vs Haskell [sic]

[S. Alexander Jacobson]

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

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

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com