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