qualified module export

[Iavor Diatchki]

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.

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 <karl at cs.tufts.edu> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161011/7e82cfb1/attachment.html>