Feature Request : Qualified module exports

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Erik de Castro Lopo-34
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.

This feature actually looks like something which I'm capable of
undertaking so if nobody thinks this is a really bad idea, I'll
have a crack at this.

Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/


Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Ian Lynagh-2
On Mon, Jul 08, 2013 at 08:14:12PM +1000, Erik de Castro Lopo wrote:
>
>    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.

Do you mean that after
    import MyModule
that
    T.f
is in scope? Won't that be confusing?

What happens if you
    import MyModule as X
?


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Roman Cheplyaka-2
In reply to this post by Erik de Castro Lopo-34
* Erik de Castro Lopo <mle+hs at mega-nerd.com> [2013-07-08 20:14:12+1000]

> 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.

What if something exports Data.Text as T, and something else exports
Data.List as T (and they obviously have lots of conflicts)?

Or what if I don't like the "T" convention and would rather like to use
the "Text" prefix?

The nice thing about the current state of Haskell modules is that you
have very fine-grained control of how your namespace looks like. I feel
that this proposal would make this control harder (if possible at all).

(BTW, I'm not denying usefulness of this, and I've seen a lot of cases
where this would be handy. I'm just pointing at the downsides.)

Roman


Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

David Luposchainsky
In reply to this post by Erik de Castro Lopo-34
On 2013-07-08 12:14, Erik de Castro Lopo wrote:

> 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'm not sure this is such a good idea.

Haskell's namespace system happens strictly during import - the importer
chooses what name to use, and a module has no influence on how it will
be referred to by other modules.

On the other side, there's the C++-like namespace system, where each
function is defined as part of some namespace, leading to the
"qualification" during export. In other words, if foo is defined in
namespace bar, you will always have to refer to it as bar::foo.

The proposal blurs the line between these two - a module can specify
under what qualified name another module is imported.

David


Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Erik de Castro Lopo-34
David Luposchainsky wrote:

> I'm not sure this is such a good idea.
>
> Haskell's namespace system happens strictly during import - the importer
> chooses what name to use, and a module has no influence on how it will
> be referred to by other modules.
>
> On the other side, there's the C++-like namespace system, where each
> function is defined as part of some namespace, leading to the
> "qualification" during export. In other words, if foo is defined in
> namespace bar, you will always have to refer to it as bar::foo.
>
> The proposal blurs the line between these two - a module can specify
> under what qualified name another module is imported.

Just about any language feature can be abused in some way. This proposal
can also be misused, but can be extremely beneficial in a number of very
common use cases.

There is a huge amount of existing code out there that does one or
more of the following two:

   import qualified Data.ByteString.Char8 as BS8
   import qualified Data.Text as T

with every module using those modules having the exact same two lines
of code. My code already has a custom Prelude which drops some dangerous
functions (head/tail etc) and adds types Text, ByteString and a couple
of my own functions. For my current project, qualified exports would
remove the above two lines from about 50 files.

If this feature was only enabled with a -XQualifiedModuleExports pragma,
would that decrease your objection?

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/


Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Ian Lynagh-2
On Mon, Jul 08, 2013 at 10:05:09PM +1000, Erik de Castro Lopo wrote:
>
> If this feature was only enabled with a -XQualifiedModuleExports pragma,
> would that decrease your objection?

If it's added, then it should definitely only be enabled when an
extension is turned on.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Nicolas Frisby
In reply to this post by Erik de Castro Lopo-34
On Mon, Jul 8, 2013 at 5:14 AM, Erik de Castro Lopo <mle+hs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130708/02d79081/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Feature Request : Qualified module exports

Simon Marlow-7
In reply to this post by Erik de Castro Lopo-34
On 08/07/13 11:14, Erik de Castro Lopo 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.
>
> This feature actually looks like something which I'm capable of
> undertaking so if nobody thinks this is a really bad idea, I'll
> have a crack at this.

There have been discussions about this in the past, here is a good one:
http://www.haskell.org/pipermail/libraries/2005-March/003390.html (read
the rest of the thread, and there are links in there to other threads).

This is a feature that at first seems simple but leads to a lot of
subtle issues.  And it's not clear (to me at least) that this is
something we want rather than some form of namespace-management at the
package level.

Cheers,
        Simon