Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))

[S. Alexander Jacobson]

Simon,

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

== Lifting The Overlap Restriction ==

The Haskell model is much simpler for the user and sacrifices little 
expressive power.

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

-Alex-

______________________________________________________________
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
> these
>> (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
> restriction.
>
> Perhaps you could elaborate on how you would implement versioning in
> that scenario, and how we could add to or change existing interfaces?
>
> Cheers,
> 	Simon
>