<div dir="ltr">Hello,<div><br></div><div>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:</div><div>   * `module T` may export only some of the names from `T` (e.g. if `M` contains `import T(onlyThisName)`); or,</div><div>   * `module T` may export the names from an entirely different module (e.g., if `M` contains `import S as T`); or,</div><div>   * `module T` may export a combination of multiple modules (e.g., if `M` contains `import S1 as T` and `import S2 as T`).</div><div><br></div><div>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]).</div><div><br></div><div>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.</div><div><br></div><div>I hope this is helpful,<br></div><div>-Iavor<br></div><div><br></div><div>[1] <a href="http://yav.github.io/publications/modules98.pdf">http://yav.github.io/publications/modules98.pdf</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 11, 2016 at 8:54 AM, Karl Cronburg <span dir="ltr"><<a href="mailto:karl@cs.tufts.edu" target="_blank">karl@cs.tufts.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>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.:</div><div><br></div><div><div>|  'module' modid             {% amsu (sLL $1 $> (IEModuleContents $2))</div><div>                                      [mj AnnModule $1] }</div><div>|  'qualified' 'module' qconid --maybeas</div><div>                              {% amsu (sLL $2 $> (IEModuleQualified $3))</div><div>                                      [mj AnnQualified $1] }</div><div><br></div></div><div>But now I'm lost in the compiler internals. Where should I be looking / focusing on? In particular:</div><div><br></div><div>- Where do exported identifiers get added to the list of "[LIE Name]" in ExportAccum (in TcRnExports.hs)?</div><div><br></div><div>Thanks,</div><div>-Karl Cronburg-</div></div>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>