[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