qualified module export

[Simon Marlow]

On 11 October 2016 at 18:04, Iavor Diatchki <iavor.diatchki at gmail.com>
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 <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
>>
>>
>
> _______________________________________________
> 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/20161013/2b9872a1/attachment-0001.html>