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