patch applied (ghc): Generalise Package Support

[Malcolm Wallace]

Simon Marlow <simonmarhaskell at gmail.com> wrote:

> 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