On Mon, Jul 8, 2013 at 5:14 AM, Erik de Castro Lopo <mle+hs@mega-nerd.com> wrote:
>
> Hi all,
>
> I've added a feature request ticket to the GHC trac:
>
> http://ghc.haskell.org/trac/ghc/ticket/8043
>
> for qualified module exports. In a nutshell this would allow the
> following 'qualified module' export eg:
>
> module MyModule
> ( qualified module T
> )
> import qualified Data.Text as T
>
> so that any module which imports MyModule has access to the symbols
> of Data.Text under the quaified module name T.

I appreciate the problem — glad you're attacking it.

I worry, though, about the extra layers of indirection for the programmer's mental name resolution algorithm. If I see a "T.foo" and no import of T, then I have to investigate each import to see which of them re-exports the qualified module T.

I have three quick alternative proposals.

1) Use CPP — no GHC patch needed. Presumably, you're importing something explicitly that would then re-export these qualified modules. One #include and one symbol occurrence like DEFAULT_IMPORTS sounds like it would do the trick. Kind of gross, but it clearly indicates where to find that extra import list.

2) Add a GHC command line option that extends the default imports beyond just Prelude. I'm guessing this would be simpler to implement than your proposal, and it to couches the conceptual changes as merely an expansion of the familiar implicit import of Prelude. It does, however, mean name resolution depends on GHC command line options to a new degree, which is kind of weird. But there's only one extra place to look for imports: wherever the command line options are coming from.

3) Refine your proposal so that the re-exported module can only itself be referenced in a qualified way. EG `importing MyModule` from your example would bring into scope MyModule.T.foo, but not T.foo. Or if MyModule is imported qualified as X, you'd have have X.T.foo. Would this be complicated to parse correctly, given the special treatment of '.'?

HTH. Good luck.