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