Hi, the vote seems to indicate acceptance so far; fine with me. Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:
However, if we do accept the proposal, it should have its own extension rather than being part of ExplicitNamespaces, for the reasons discussed earlier: code needs a way to declare that it is using a new extension, so that it can properly be rejected by older versions of the compiler that don't support the extension.
Earlier we discussed the question of whether we want to allow minor changes to unextendd Haskell without extensions (and the consensus was no). This does not imply that we forbid ourselves from extending the range of existing GHC language pragmas. From a user point of view, having “ExplicitNamespaces” allow me to explicitly name the namespaces of an identifier in identifier lists such as export, import and fixity lists is very natural. It would be strange if I need “ExplicitNamespaces” for export and import lists, but “ExplicitNamespacesFixities” in fixitiy lists. I am sure others can give concrete examples where the syntax of language extensions has evolved without introducing a wealth of new extensions (and having to support all combinations). TemplateHaskell splices maybe? RebindableSyntax maybe? So is there a sensible way we can avoid fringe language extension pragma proliferation? Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/