<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
Unless I am missing the point, I can’t really make an informed decision<br>
before we have concluded our policy discussion, in particular, on<br>
whether we want to go towards a future where everyone is welcome to<br>
turn extensions on and off to build their little fine-grained preferred<br>
language islands, or whether that is something we want to avoid and use<br>
extensions only as stepping stones towards a ((eventually) single)<br>
future Haskell, at the cost of having to tell some people that they<br>
can’t expect that every possible dialect of Haskell will be supported.

</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I don't think these two are incompatible.  Even if we have a "single future Haskell" in mind, it's fair enough for people to switch things on and off if they want.   Offering flexiblity at low cost seems OK to me; other things being equal, it's not for us to say what they should or should not want.  (If the implementation or maintenance cost was high I might think again, but I don't think it is in this case.)  </div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Mar 2023 at 16:58, 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">Hi,<br>
<br>
Am Montag, dem 06.03.2023 um 16:04 +0300 schrieb Vladislav Zavialov:<br>
> Does anyone have objections? If not, I will mark the proposal<br>
> accepted in 2 weeks.<br>
<br>
not a full fledged objection yet, but I am unsure how that fits with<br>
the overall direction we have for namespaces, as outlined in<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst</a><br>
<br>
It this meant to be a short-gap measure that helps us to get to towards<br>
a bolder destination?<br>
<br>
Or is it a half-way step for people who like type-level computation,<br>
but don’t want to go all the way, and is expected to stay around?<br>
<br>
(Or maybe I am missing the point.)<br>
<br>
Unless I am missing the point, I can’t really make an informed decision<br>
before we have concluded our policy discussion, in particular, on<br>
whether we want to go towards a future where everyone is welcome to<br>
turn extensions on and off to build their little fine-grained preferred<br>
language islands, or whether that is something we want to avoid and use<br>
extensions only as stepping stones towards a ((eventually) single)<br>
future Haskell, at the cost of having to tell some people that they<br>
can’t expect that every possible dialect of Haskell will be supported.<br>
<br>
Cheers,<br>
Joachim<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>