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?

-Edward



On Mon, Oct 14, 2013 at 11:39 AM, Simon Marlow <marlowsd@gmail.com> 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
http://ghc.haskell.org/trac/ghc/wiki/ModuleReexports
and for discussion, I suggest to use the trac ticket
http://ghc.haskell.org/trac/ghc/ticket/8407

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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries