<div dir="ltr"><div class="gmail_quote"><div>Hi Joachim,</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* It seems to be inconsistent to allow both `type` and `data` in the <br>
  filtered-import, but as a qualifier on individual only `type`. Should<br>
  we allow the use of `data` in import/export lists as well?<br>
<br>
  import N(f, type (++), data (+))<br></blockquote><div><br></div><div>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.</div><div><br></div><div>However, I think you make a very good point: both of those qualifiers should be enabled by the same extension, ExplicitNamespaces.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* As discussed in<br>
  <a href="https://github.com/ghc-proposals/ghc-proposals/issues/551" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/issues/551</a>,<br>
  -XExplicitNamespaces, which is quite old and is implied by <br>
  -XTypeOperators which is implied by -XGHC2021 probably ought to have<br>
  been in GHC2021 as well, and I’d like to include it in GHC2023 (if <br>
  that exists) to fix that (see #559). But that feels inappropriate<br>
  if we extend that extension in this way.<br>
<br>
We could side-step that issue if we put he new forms in their own<br>
language extension (maybe -XNamespacedImport)? WDYT?<br></blockquote><div><br></div><div>#281 also modifies ExplicitNamespaces to enable inline "type" qualifiers in expressions. Do you want a separate extension for that also?<br></div></div></div>