#9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by dfeuer: Old description:

It's generally inadvisable to add exports to a well-known module because they may clash with existing code using the module and importing it in its entirety. As a work-around, I propose allowing a module to export a name that will only be visible in a module that lists it explicitly. Something approximately like

module Foo (a, b, explicit c)

simply

import Foo

would not bring c into scope, but

import Foo (c)

would bring in c (and nothing else). To get everything, we could use something like

import Foo revealing (c)

and to be a bit picky,

import Foo hiding (a) revealing (c).

New description: It's generally inadvisable to add exports to a well-known module because they may clash with existing code using the module and importing it in its entirety. As a work-around, I propose allowing a module to export a name that will only be visible in a module that lists it explicitly. If we had module Foo (a, b, hidden c) then simply import Foo would not bring c into scope, but import Foo (c) would bring in c (and nothing else). To get everything, we could use something like import Foo revealing (c) and to be a bit picky, import Foo hiding (a) revealing (c). -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9191#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9191: Semi-exported names -------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dfeuer): Replying to [comment:3 carter]:

Do you think those works will subsume your proposal?

I don't believe so. Backpack appears to build a whole new layer on top of the primitive module system to impose constraints on modules, support separate type-checking, etc. It (or something similar) looks likely to become an important part of the Haskell ecosystem, supporting large projects and interdependent libraries. My proposal is a much more restricted one, filling in a small gap in the underlying module system itself that can cause trouble when modifying a module that ''old'' code imports in its entirety. This old code (which, since it uses unrestricted module import, was probably written with more of an eye toward release date than long-term maintenance) may never be retrofitted to use a system like Backpack. The specific use-case I had in mind was adding `uncons :: [a] -> Maybe (a, [a])` to `Data.List`. It obviously ''belongs'' there, but adding it could break a lot of modules that just `import Data.List`. If it were possible to make it hidden, so only modules that want it would get it, then all would be fine. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9191#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler