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

[Vladislav Zavialov]

Hi Joachim,

* 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 (+))
>

The "data" qualifier is also in the proposal, but it's behind
PatternSynonyms rather than ExplicitNamespaces. That's because it is meant
to replace the "pattern" qualifier, which is currently enabled by
PatternSynonyms.

However, I think you make a very good point: both of those qualifiers
should be enabled by the same extension, ExplicitNamespaces.


> * 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?
>

#281 also modifies ExplicitNamespaces to enable inline "type" qualifiers in
expressions. Do you want a separate extension for that also?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221208/65a7bf7d/attachment.html>