Feature Request : Qualified module exports
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/
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
* Erik de Castro Lopo
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
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
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/
On Mon, Jul 8, 2013 at 5:14 AM, Erik de Castro Lopo
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.
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
participants (6)
-
David Luposchainsky -
Erik de Castro Lopo -
Ian Lynagh -
Nicolas Frisby -
Roman Cheplyaka -
Simon Marlow