Module reexports at the package level

[Simon Marlow]

On 14/10/2013 19:33, Joachim Breitner wrote:

> thanks for looking at this. You are missing an important bit of
> semantics in my proposal: Current, if two packages foo and bar are
> visible, both of which provide Data.Foo, you cannot use "import
> Data.Foo" – even if one is a re-exporting stub as you suggest. With what
> I have in mind, if foo re-exports bar’s Data.Foo, such an import would
> be accepted. I believe this is important, as it allows package
> restructuring with less breaking existing code.

Yes, good point.  This wasn't an issue when we were using stubs before, 
because you would be using *either* base-3 or base-4, but not both.

> There is an alternative solution to this: Use re-exporting stub modules
> (as you suggest), but make GHC more liberal when multiple modules of the
> same name are important: E.g.
>   * ignore one if it exports precisely the same set of names and values, or
>   * if it exports a subset, or even
>   * only complain if an ambiguous _name_ is used from the module, and do
>     not complain if a name is used that is exported only by one Data.Foo,
>     or is exported by both, but referring to the same symbol.
> These have their merits (more powerful), but can also be abused more, so
> but I prefer the original, less ad-hoc and more declarative approach.

The third option sounds reasonable, as a generalisation of the way 
ambiguous identifiers are currently handled.  In fact, if we want to 
re-export only a subset of the original module, then we have to use a 
stub (rather than re-exporting at the package level), and so we end up 
needing this change to ambiguity checking.

Re-exporting a subset of another module is common.  If we're providing 
an old API in terms of a new one, each of the modules of the old API 
will re-export the subset of the new API that corresponds to the old API.

Cheers,
Simon