Hi, Am Montag, den 14.10.2013, 17:39 +0200 schrieb Simon Marlow:
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.
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. 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. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org