On the first point , I suggest we propose it in the thread and see what the author has to say.

On the second point I am all in favour of splitting out -XNamespacedImport.

Chris


On 7 Dec 2022, at 18:12, Joachim Breitner <mail@joachim-breitner.de> wrote:

Hi,

generally in favor; these new warnings shoudn’t do harm and are
hopefully useful to some.

But I have a technical issue (sorry for being so late with that):

I note that this proposal extends -XExplicitNamespaces, which so far
can be used to distinguish type from term operators in export and
import lists, by allowing them to be prefixed with `type` (but not
`data`!), as in: import N( f, type (++) )
https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/explicit_namespaces.html

The new extension now extends this extension the

 import qualified Foo data as FD
 import qualified Foo type as FT

forms to “filter” imports by namespace.  A few points:

* It seems to be inconsistent to allow both `type` and `data` in the 
 filtered-import, but as a qualifier on individual only `type`. Should
 we allow the use of `data` in import/export lists as well?

 import N(f, type (++), data (+))

* As discussed in
 https://github.com/ghc-proposals/ghc-proposals/issues/551,
 -XExplicitNamespaces, which is quite old and is implied by 
 -XTypeOperators which is implied by -XGHC2021 probably ought to have
 been in GHC2021 as well, and I’d like to include it in GHC2023 (if 
 that exists) to fix that (see #559). But that feels inappropriate
 if we extend that extension in this way.

We could side-step that issue if we put he new forms in their own
language extension (maybe -XNamespacedImport)? WDYT?

Cheers,
Joachim
--
Joachim Breitner
 mail@joachim-breitner.de
 http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee