Hi, Am Dienstag, den 15.10.2013, 09:50 +0200 schrieb Simon Marlow:
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.
you really think so? I was not bold enough to suggest that, but OTOH many nice things can be done with it (and many non-nice). For example, if we’d implement that, it means that packages can start to provide a module named "Prelude" to automatically and conveniently amend the default imports. While it would definitely solve my itch, I’m a bit worried that it would open the floodgates to quite messy cross-package modules. 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