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

Joachim Breitner mail at joachim-breitner.de
Wed Dec 7 18:12:23 UTC 2022


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 at joachim-breitner.de
  http://www.joachim-breitner.de/



More information about the ghc-steering-committee mailing list