build-depends harmful (was RE: import resolution)

[S. Alexander Jacobson]

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.

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.

-Alex-

PS I hope this finally makes sense....

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








On Fri, 15 Apr 2005, S. Alexander Jacobson wrote:

> On Thu, 14 Apr 2005, Simon Peyton-Jones wrote:
>> The Right Thing to
>> do must be to regard the "full module name" as being the package name
>> pre-pended to the module name.
>
> I don't think that is right.  As far as I understand, module names in import 
> statements identify specifications not implementations. Otherwise, it would 
> be incorrect for different compilers to implement the Prelude differently. 
> Resolution of imported module names to meanings or specifications is 
> fundamentally different from resolution of module names to implementations. 
> The former is the domain of the programmer and the later is the domain of the 
> compiler/interpreter.
>
>> b) We worry about error messages like "cannot unify M.T with M.T"
>> (meaning different M's!)
>
> I think the Haskell report is pretty clear that M.T always means M.T. So, I 
> interpret this as an error in the status quo that can result from multiple 
> packages requiring conflicting implementations of M.
>
> The core problem here is that packages should not be *requiring* 
> implementations of anything.  They should only be providing them.
>
> Under the package overlap restriction, containment is identical with 
> requirement.  So the pacakge overlap restriction is a minor instance of this 
> problem A much more major instance results from putting build-depends tags in 
> cabal files.  Instead of being unable to use package A with package B if both 
> *contain* an implementation of Foo.Baz, build-depends means that you are 
> unable to use package A with package B if both *require* an implementation of 
> Foo.Baz.  The likelihood of conflict therefore rises considerably.
>
> What we really need here is Hackage on steroids; a way for 
> compilers/interpreters to look up module names in shared 
> directories/name-servers in order to obtain packaged implementations that are 
> compatible with the target platform (perhaps via a compile) and with each 
> other (if the package overlap restriction survives).
>
> I know we've been going back and forth on this discussion for a while and my 
> position has changed some.  I want to thank you for your patience.  I hope 
> this post finally makese some sense.
>
> -Alex-
>
> * I think we should also have a somewhat more explicit system for allocating 
> module namespace, but that is a whole separate discussion whose resolution is 
> dependent on this one.
>
> PS Though I didn't quote them, I think this post also addresses the concerns 
> expressed in David Roundy, Wolfgang Thaller, Simon Marlow's and Isaac Jones. 
> If not, please advice.
>
>
> ______________________________________________________________
> S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>