Re: patch applied (ghc): Generalise Package Support
Malcolm Wallace wrote:
I would caution against changing the syntax of imports too hastily. As I recall, the outcome of the mailing list discussion (and wiki) on this issue was that the proposed syntax changes do not give any new expressive power over packages, that we do not already have (via OPTIONS_GHC etc). Given that the user can already say everything about packages they need to, in the source code, I question whether arbitrarily breaking source-compatibility with other implementations (and Haskell'98) is wise.
Well, firstly we don't currently support using -package options inside OPTIONS_GHC, but that's certainly one option. Leaving it there is certainly attractive, because there's not much to do, and as you say it keeps the language changes to a minimum. It's also very close to the .NET story. Package-qualified imports give you two qualitative benefits over per-module -package flags: - they let you disambiguate imports in a single module - they let you use packages without populating the global module namespace Some people wanted to move in the direction of using package-qualified imports for *everything*, that is moving away from a single global module namespace. Certainly having a per-package module namespace is useful: for example in the GHC package we don't want to have to rename all our modules to be hierarchical, but in the absence of package-qualified imports we will probalby be forced to do that to avoid probable clashes in the global module namespace. I see the package-qualified import story as quite attractive. It's quite lightweight, easy to understand and not too hard to implement, and the fact that it parallels the story at the module level means that it is intuitive. I wouldn't say I'm completely sold on it (but Simon PJ is, I think). I'm not sure what the Cabal story would be if package flags are allowed in OPTIONS_GHC, it seems a bit hairy. On the other hand, Cabal works quite naturally with package-qualified imports - we just need a way to say in build-depends that a package dependency should not populate the global module namespace. Cheers, Simon
Simon Marlow
I wrote:
I would caution against changing the syntax of imports too hastily.
Well, firstly we don't currently support using -package options inside OPTIONS_GHC, but that's certainly one option.
Ah, nhc98 already does (and it is the preferred mechanism for us).
Package-qualified imports give you two qualitative benefits over per-module -package flags:
- they let you disambiguate imports in a single module - they let you use packages without populating the global module namespace
I would say that both benefits are likely to be rarely used, and on the occasions they are needed, can be achieved by other means. Disambiguation can be done at the cost of two extra modules just to re-export the entities with overlapping names. That's about six lines of code, which is perfectly clear and not in any way obfuscatory of what is really happening.
Some people wanted to move in the direction of using package-qualified imports for *everything*, that is moving away from a single global module namespace.
I must say I'm not keen on that. A single global module namespace, vs a single global package namespace. What's the difference really? Since we can now "fake" the former even when it isn't really true, I'd say keep it that way.
Certainly having a per-package module namespace is useful: for example in the GHC package we don't want to have to rename all our modules to be hierarchical, but in the absence of package-qualified imports we will probalby be forced to do that to avoid probable clashes in the global module namespace.
Hmm. Renaming all the GHC modules to fit under Language.Compiler.GHC would not be *that* hard a job, and darcs makes it especially easy. Introducing a new language feature just to avoid an hour's tedious work seems like a rather geeky tradeoff. :-)
I'm not sure what the Cabal story would be if package flags are allowed in OPTIONS_GHC, it seems a bit hairy. On the other hand, Cabal works quite naturally with package-qualified imports - we just need a way to say in build-depends that a package dependency should not populate the global module namespace.
It seems to me that for Cabal, you just list all the dependencies. That's it isn't it? Cabal should not add any -package flags to the compiler, because each module that actually uses a package just has to name it in the OPTIONS_GHC line. After all, with package-qualified imports, you would be asking users to name the packages in the source code directly anyway, so it is no extra work for the user. Regards, Malcolm
participants (2)
-
Malcolm Wallace -
Simon Marlow