On 01 April 2005 07:31, S. Alexander Jacobson wrote:
I want to allow the user to know exactly which implementations they are using when they import a module-id while at the same time giving them maximal choice of implementations to use. Everything else here is just details.
I'll comment on the overall goal then: I'm in complete agreement that requiring dependencies to be specified is a good thing. For some reason you want to do this with language extensions or compiler extensions rather than using Cabal - but this is one of the things that we expected Cabal to address, which is why you're getting some pushback. I'm interested in why you're avoiding Cabal: if you could elaborate on that (perhaps in a separate thread) we might be able to make some improvements. You've identified a few problems with the current system: (a) some packages are exposed by default, which leads to people being able to write code without knowing (or needing to know) which packages they're using, resulting in untracked dependencies. I think this is a compromise, and I think it's a good one. Being able to just import any of the hierarchical modules I have installed on my system without having to give a -package flag is really useful (don't touch that keyboard! I haven't finished yet :-). If I decide that I want to give the code to someone else, then the dependencies become important. This is where Cabal comes in: if you're not already using Cabal as a plain build system, then you probably want to use it to ship the code to someone else anyway. And at that point you're forced to enumerate the dependencies. Sure, we currently have a problem that the dependencies in Cabal are unchecked, but that's just a bug. (I'm coming around to Isaac's earlier suggestion of -fhide-all-packages, actually). (b) dependencies aren't specified per-module. I can't express that I expect module M to come from package P. I see this as documentation, but I agree it's useful documentation, and it would be even more useful if it were automatically checked. I don't see any fundamental problem with adding this to Cabal.
* Oh, we made local changes too!? What were they?
Does Cabal/Hackage notify the user of differences between official packages and local versions? If not, this is another untracked dependency.
If you modify a package, you're required to give it a new version number and/or a different package name. No this isn't checked, but it could be (calculating a hash of the external interface of the package, for example).
* But what happens if I don't have root/admin on the target machine? [...] * Oh, this package conflicts with something already installed? [etc.]
Are some packages allowed to modify the haskell implementation itself? More risk of untracked dependencies.
Nope, they aren't (fortunately). This is one reason we removed the extra_ghc_options field that used to be in the package config. Cheers, Simon