Re: qualified module export

On 11 October 2016 at 18:04, Iavor Diatchki wrote:

Hello,

There may be some more thinking to be done on the design of this feature. In particular, if a module `M` has en export declaration `module T`, this is not at all the same as adding `import T` in modules exporting `M`. The reason is that meaning of `module T` depends on what is in scope in `M` and with what names. For example: * `module T` may export only some of the names from `T` (e.g. if `M` contains `import T(onlyThisName)`); or, * `module T` may export the names from an entirely different module (e.g., if `M` contains `import S as T`); or, * `module T` may export a combination of multiple modules (e.g., if `M` contains `import S1 as T` and `import S2 as T`).

So, I would expect an export of the form `qualified module T as X` to work in a similar fashion (for the full details on the current semantics you could have a look at [1]).

The next issue would be that, currently, entities exported by a module are only identified by an unqualified name, and the imports introduce qualified names as necessary. It might make sense to allow modules to also export qualified names instead, but then we'd have to decide what happens on the importing end. Presumably, a simple `import M` would now bring both some qualified and some unqualified names. This means that the explicit import and hiding lists would have to support qualified names, seems doable. However, we'd also have to decide how `import M as X` works, in particular how does it affect imported qualified names. One option would be to have `X` replace the qualifier, so if `A.b` is imported via `import M as X`, the resulting name would be `X.b`. Another option would be to have `X` extend the qualifier, so `A.b` would become `X.A.b` locally. Neither seems perfect: the first one is somewhat surprising, where you might accidentally "overwrite" a qualifier and introduce name conflicts; the second does not allow exported qualified names to ever get shorter.

Yes, I think this is an important consideration. It's much simpler if we can think of the set of names that a module exports as just strings (possibly containing dots), and an import brings those names into scope, possibly prepending a qualifier. That's a simple story, but it doesn't let you change the qualifier at import time. The question is, do we think it's important to allow that? Suppose Data.Text exported the Text type and everything else qualified by Text: Text.null, Text.concat, etc. Now you wouldn't be able to rename the qualifier to T if you wanted to. Many people do this. Perhaps people would lobby to have Data.Text.Unqualified so that they could do "import qualified Data.Text.Unqualified as T", but then we haven't really made anything better. Cheers Simon I hope this is helpful,

-Iavor

[1] http://yav.github.io/publications/modules98.pdf

On Tue, Oct 11, 2016 at 8:54 AM, Karl Cronburg wrote:

...

Hello,

I'm attempting to add support for export of qualified modules (feature request #8043), and any guidance would be greatly appreciated. Namely I'm very familiar with languages / grammars / happy and was easily able to add an appropriate production alternative to Parser.y to construct a new AST node when 'qualified module' is seen in the export list, i.e.:

| 'module' modid {% amsu (sLL $1 $> (IEModuleContents $2)) [mj AnnModule $1] } | 'qualified' 'module' qconid --maybeas {% amsu (sLL $2 $> (IEModuleQualified $3)) [mj AnnQualified $1] }

But now I'm lost in the compiler internals. Where should I be looking / focusing on? In particular:

- Where do exported identifiers get added to the list of "[LIE Name]" in ExportAccum (in TcRnExports.hs)?

Thanks, -Karl Cronburg-

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs