Cabal vs Haskell (was RE: build-depends harmful (was RE: import
S. Alexander Jacobson
alex at alexjacobson.com
Tue Apr 19 20:59:54 EDT 2005
You appear be proposing to change the definition of a Haskell program
from a set of Haskell modules connected by import to a set of Cabal
packages connected by build-depends. I am going to call the former
the Haskell model and the later the Cabal model. In this mesage I
hope to convince you that the Haskell model is simpler for the user to
understand in the context of package overlap, more robust with respect
to change, and more adaptable to various usage contexts. I hope to
convince you that the Haskel model is stricly superior to that of
== Lifting The Overlap Restriction ==
The Haskell model is much simpler for the user and sacrifices little
Under the Haskell model, M.T means the same thing in every module and
lifting the overlap restriction means programs just have a lookup
table mapping module names to module locations; resolution follows
simply and directly without worrying about package structure.
Under the Cabal model, M.T can mean different things in different
modules and lifting the overlap restriction means programs must have a
lookup table mapping package name/module name pairs to module
locations. Resolution in this case is complex. It depends on both
the other contents of the package supplying the importing module AND
the build-depends tag of that module.
== Handling Change/Versioning ==
Haskell model programs are MUCH more robust with respect to change
than programs under the Cabal model.
Under the Haskell model, only module interface changes can break a
program. However, module interface changes that actually break a
program are relatively rare because most changes simply involve adding
new functions and the remainder can be managed reasonably using the
*Deprecated* tag (no need for an elaborate versioning scheme).
Under the Cabal model, module interface changes can also break a
program, but so can changes in build-depends tags. The big problem is
that changes in build-depends tags are VERY LIKELY to break programs.
For example, suppose package P1 is modified to build-depend on a new
version of package P2. Now every other package that also uses P2 must
also be updated. And if the new version of P2 build-depends on a new
verion of P3, now every other package that uses P3 must also be
updated, etc, etc. Catastrophe!
== Adaptability ==
Haskell model programs can better adapt to usage context than programs
using the Cabal model.
For example, suppose someone produces an implementation of module M
that works especially well on a particular platform/OS or fulfills a
particular memory/cpu tradeoff.
Under the Haskell model, a user would be free to use such in
implementation in any program that uses module M.
Under the Cabal model, the user could use this module only in programs
that build-depends on versions of packages that know to provide this
implementation in this particular context.
== Hackage ==
Haskell Hackage is a mapping from module names to package locations.
Cabal Hackage is a mapping from package names to package locations.
== Conclusion ==
You said earlier that module names should be functional and package
names should be administrative. To me, that is a clear endorsement of
the Haskell model. However, in this discussion you and SPJ appear to
have drifted away from it. I hope I have convinced you to stick with
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Tue, 19 Apr 2005, Simon Marlow wrote:
> On 18 April 2005 21:18, S. Alexander Jacobson wrote:
>> I just reread my prior post and realized that it was not entirely in
>> english. Trying again...
>> Module names in import statements refer to module specifications not
>> module implementations. e.g. if Prelude refers to a spec not an
>> implementation, then use of any module that uses the Prelude must also
>> refer to a spec rather than an implementation.
>> Module users select hardware platform, operating system, compiler,
>> etc. They should also be selecting the best modules implementations
>> for their context. Module packagers lack enough information about user
>> context to do so.
>> The problem with build-depends and the Package Overlap Restriction is
>> that they move decision making from module users to module packagers.
>> Build-depends is far more egregious than POR and far more optional.
> I think you misunderstand build-depends. It allows the author of a
> library to specify which implementations of a dependency are compatible
> with the source code of the current package; i.e. which packages will
> satisfy the dependency.
> (I'd be happier if you'd call the Package Overlap Restriction the Module
> Overlap Restriction, since it really has nothing to do with packages:
> Haskell 98 contains this restriction).
>> Packages should simply be collections of module implementations with
>> meta-data about how/where those implementations are best used.
>> Users should then select implementations from (Hackage) catalogs of
>> (Cabal) packages as needed.
>> Therefore, we need to remove build-depends tags from Cabal files (or
>> change their semantics), and make Hackage a full catalog
>> serving/replication protocol.
> Removing build-depends would impose the restriction that a module can
> never change its interface, ever. Additionally, users are required to
> choose between available implementations, whether they want to or not.
> This appears to be the nub of the issue: I'm opposed to adding this
> Perhaps you could elaborate on how you would implement versioning in
> that scenario, and how we could add to or change existing interfaces?
More information about the Libraries