Module reexports at the package level

Edward Kmett ekmett at
Mon Oct 14 16:08:22 UTC 2013

There is one element beyond convenience.

If you launch GHCi, and load Data.Foo, then if we follow the PackageImports
path there will be two modules with the same name and the choice of where
to load it from will be flagged as ambiguous, asking if you meant Data.Foo
from "foo" or Data.Foo from "bar", no?


On Mon, Oct 14, 2013 at 11:39 AM, Simon Marlow <marlowsd at> wrote:

> On 04/10/2013 11:07, Joachim Breitner wrote:
>> not sure if this is the right mailing list, as it affects GHC and Cabal,
>> but can be used by all library authors. But it is a close fit.
>> I’d like to propose Module re-reports on the package level, in order to
>> make package reorganization easier on the users. For details, please see
>> and for discussion, I suggest to use the trac ticket
>> Questions are:
>>   * Is this useful enough?
>>   * Is the design (syntax and semantics) good?
> It's not clear whether it's worth doing this, because it doesn't add any
> new functionality, only convenience.  To re-export a module from a package
> you can already write a stub module like this:
>   {-# LANGUAGE PackageImports #-}
>   module Data.Foo (module X) where
>   import "foo" Data.Foo as X
> so the convenience would be not having to write (or automatically
> generate) all these stub modules.
> You could implement package re-exports by automatically generating these
> stub modules, which would require only changes in Cabal.  Or you could
> implement them directly, which would need changes in lots of places - when
> I considered doing this before, I concluded that it probably wasn't worth
> it.
> Cheers,
> Simon
> ______________________________**_________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list