Module Holism (was RE: exposed packages and cabal depends)
simonmar at microsoft.com
Tue Apr 12 04:15:38 EDT 2005
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
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
>> 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 ]
More information about the Libraries