<div dir="ltr">As it currently stands, it seems to me that the proposal is pretty modest. I'm in favour of the proposal, provided that the technical details are resolved to Joachim satisfaction.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 8 Dec 2022 at 09:33, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(replying to the whole list, full quote)<br>
<br>
Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav<br>
Zavialov:<br>
> I agree with your observation that namespaced imports are somewhat<br>
> different from simply specifying the namespace of a single name, so<br>
> they could be separated into their own extension. But if that is the<br>
> reasoning that we choose to follow, then the changes in #281 should<br>
> *definitely* go into their own extension: they affect not just names<br>
> but entire expressions and patterns, including their grammar (not<br>
> just namespacing).<br>
> <br>
> The only reason the changes in #270 and #281 are included in<br>
> ExplicitNamespaces is to reduce the amount of language flags. If you<br>
> prefer fine-grained control and immutable extensions, then both of<br>
> those changes need separate flags for them.<br>
> <br>
> So, if we are consistent, we have two options:<br>
> 1. Include changes in #270 and #281 in ExplicitNamespaces on the<br>
> grounds that they include explicitly specify a namespace (even though<br>
> that is not the only thing they do)<br>
> 2. Create separate language extension flags: NamespacedImports and<br>
> TypesInExpressions (names to be discussed)<br>
> <br>
> I happen to prefer (1), and that is the approach that the proposals<br>
> currently follow, but I am not opposed to (2) either.<br>
<br>
I don’t prefer fine-grained flags per se. In fact, my ideal world is<br>
one perfect language with no flags :-). So I think I’d prefer all under<br>
ExplicitNamespaces as well, and I think the only reason I am hesitant<br>
is that I believe the old ExplicitNamespaces should have been in<br>
GHC2021, so it should be in GHC2023, and am unsure if the<br>
(comprehensive) ExplicitNamespaces should be there.<br>
<br>
This gives us (at least) these options:<br>
<br>
1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, <br>
   introduce one or two new extensions for the newer changes.<br>
2. Extend ExplicitNamespaces, and don’t add it already to GHC2023,<br>
   disregarding issue #551.<br>
3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023,<br>
   arguing that GHC20xx allows more liberal (backward-compatibile)<br>
   changes than, say, Haskell2010 would allow.<br>
<br>
Certainly 1 is the least bold move. I am not sure what the best way<br>
forwards is, and welcome other opinions.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>