Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept

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 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_name...

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