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

[S. Alexander Jacobson]

On Wed, 20 Apr 2005, Simon Marlow wrote:
> Not at all - the definition of a Haskell program is still a collection
> of modules with distinct names.  If we were to "lift the overlap
> restriction" then the definition would change to a collection of modules
> with distinct (package name, module name) pairs.

Yes, I understand this and oppose it.  Packages should just be 
encapsulations of module implementations; they should have no 
functional signficance.  Making package names part of module names 
endows them with functional significance, adding fragility and 
rigidity without providing any compensating values.

Fragility
Changes in code should be as local as possible.  If package names are 
part of module names than a change to any module in any package that 
is part of a program can require changes to every other package in 
that program (to update package names).  If packages simply 
encapsulate module implementations, then only modules that relied on 
the old interface need be changed.

Rigidity
Users should be able to select module implementations most appropriate 
for their contexts.  If package names are part of module names, they 
can't do that.  If packages are simply encapsulations of various 
module implementations then they can. (e.g. one package supplies a 
general purpose version of module M, while another supplies a version 
that takes special advantage of some feature of GHC 6.2, while another 
is optimized for some obscure CPU. The user should be able to select 
the package that is right for him/her).

Complexity
Note, I don't know what the user interface to adding package names to 
import statements would be, but I strongly suspect that it will be 
harder to understand than the current module names are just functional 
model.

Lastly, I think you proposal to add package naes to the source is 
seriously at odds with your commment from earlier:

   Also, the Haskell module hierarchy is supposed to reflect
   functionality, whereas package names are purely administrative.
   This is a reason for not including package names in source code.

   http://www.haskell.org//pipermail/libraries/2005-April/003513.html

I think the earlier point made much more sense.

-Alex-

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


On Wed, 20 Apr 2005, Simon Marlow wrote:

> On 20 April 2005 02:00, S. Alexander Jacobson wrote:
>
>> 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.
>
> Not at all - the definition of a Haskell program is still a collection
> of modules with distinct names.  If we were to "lift the overlap
> restriction" then the definition would change to a collection of modules
> with distinct (package name, module name) pairs.  Two changes are
> required:
>
>   - define module name as (package name, module name) pair
>
>   - in the context of each module's source, there is a mapping from
>     module name to package name that is used to resolve an import.
>
> the definition doesn't require Cabal, or build-depends.
>
> Given that this model doesn't rely on Cabal or build-depends, I'm afraid
> I don't understand the rest of your post.  I think you may have
> misunderstood what the module overlap restriction is.
>
>> == 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.
>
> If programs are still collections of modules with distinct names, then
> the module overlap restriction is still in place.
>
> Perhaps you could define some terms more precisely, to avoid confusion:
> for example things like "module location", and what you understand by
> "overlap restriction".
>
> Cheers,
> 	Simon
>