Opened 2 years ago

Closed 20 months ago

#9191 closed feature request (invalid)

Semi-exported names

Reported by: dfeuer Owned by:
Priority: low Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by dfeuer)

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

Change History (5)

comment:1 Changed 2 years ago by dfeuer

  • Component changed from Compiler (CodeGen) to Compiler

comment:2 Changed 2 years ago by dfeuer

  • Description modified (diff)

comment:3 follow-up: Changed 2 years ago by carter

While the *goal* of this suggestion is great, the *means* is a bit questionable, or at least theres some folks already working to spec out an even better approach (though nothings mature yet)

I think the work in progress to endow GHC with a module type system actually subsumes this idea. see and

In that setting, you import wrt a *signature* of what you expect a module to have, which will be a subset of the module exports. This naturally solves your revealing/hiding/hidden/explicit notions in a much nicer way I think.

Do you think those works will subsume your proposal?

comment:4 in reply to: ↑ 3 Changed 2 years ago by dfeuer

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

comment:5 Changed 20 months ago by dfeuer

  • Resolution set to invalid
  • Status changed from new to closed

As this has generated no interest from anyone but me, I'll close it out.

Note: See TracTickets for help on using tickets.