Module Holism (was RE: exposed packages and cabal depends)

[Simon Marlow]

On 12 April 2005 01:28, S. Alexander Jacobson wrote:

> On Mon, 11 Apr 2005, Simon Marlow wrote:
>>> The problem is, we don't want to import two modules, only to
>>> discover that somewhere in their dependencies they each use the
>>> same module name to refer to conflicting module implementations.
>> 
>> This is the problem that the overlap restriction leads to, yes.
> 
> No, you have this problem even with atomic modules. It is a result
> simply of not allowing two modules to share the same name in the same
> program and has nothing to do with package overlap.

When I say "overlap restriction" I mean the restriction that prevents
having two modules with the same name in the same program.

>>> Therefore, we really want to say that no two modules we might want
>>> to import into our programs (either directly or indirectly) should
>>> share the same name.  And, in particular, we don't want a packaging
>>> or versioning system that encourages it!
>> 
>> No, you've drawn a bogus conclusion again.  We most definitely want
>> the ability to choose between multiple instances of a particular
>> module in programs.
> 
> My point is that the choice of instance should be made at
> compile/build/run times and not at packaging time.

Dependencies must be expressed at package time, otherwise they are
untracked dependencies.  Right?

A package must state that it needs implementation P of module M rather
than implementation Q, otherwise there's a chance that the guy building
the package will get the wrong one.

Build-depends lets you select an implementation from a range (currently
it's just a version range, but we could make the language more
expressive and include alternatives, I doubt it would be that useful in
practice, though).

So dependencies are selected at compile time.  Selecting dependencies at
run-time (I assume this is what you mean by late binding) is another
kettle of fish: at least, it would mean that GHC couldn't do its
aggressive cross-module optimisation against the library that you're
late-binding to.  But I think it's worthwhile investigating to what
extent this is possible, so that we can have upgradable shared
libraries.

>> For example, if I have two versions of a package installed,
>> say P-1 and P-2, I want to be able to compile my old code that
>> depends on P-1 while still being able to write new code against P-2.
>> And I want to be able to use other packages that still depend, for
>> the time being, on P-1.  When P-3 comes out, I don't want to be
>> forced to uninstall P-1 and P-2 before I can use it.
> 
> Now what happens when you want to use one package that depends on P-1
> and another that depends on P-2 at the same time?

Of course, you can't do that.  That's what the "overlap restriction"
prevents.  As I've explained.

[ the next three paragraphs, which I deleted, all complain about
scenarios which we can't handle because of the overlap restriction.  I
don't think I need to comment any further. ]

[ more stuff deleted, this thread is too long already ]

Cheers,
	Simon