patch applied (ghc): Generalise Package Support
simonmarhaskell at gmail.com
Fri Jul 28 10:52:07 EDT 2006
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
Package-qualified imports give you two qualitative benefits over per-module
- 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
More information about the Libraries