<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">
* MonoLocalBinds<br>
<br>
Not an expert, but people say it’s simpler and needed to stay sane with<br>
GADTs. Yes, sometimes annoying (local parser helper etc.), but in those<br>
cases an explicit type signature is probably nice as well. Leaning<br>
towards yes.
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I agree. But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Reason: extensions generally allow more programs, not fewer. PolyLocalBinds does that -- at the expense of less predictable type inference. To get predictable type inference with GADTs we switch PolyLocalBinds off.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story.</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 Tue, 21 Nov 2023 at 17:18, 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>
thanks for pushing more and well-justified proposals.<br>
<br>
Allow me to collect my thoughts on the individual additions proposed at<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst</a><br>
(generally, I’m guess I'm an inclusionist here)<br>
<br>
* DataKinds and TypeData<br>
<br>
Leaning towards yes for DataKinds, unsure for TypeData, and will bow in<br>
if this turns out to be contentious. It feels like a step in the right<br>
direction, but I am not a heavy user.<br>
<br>
* DerivingStrategies<br>
<br>
Being more explicit seems to be useful, e.g. with documentation, and it<br>
certainly doesn’t hurt. In favor.<br>
<br>
* DisambiguateRecordFields <br>
<br>
Small quality-of-life improvement, so sure, why not. In favor, unless I<br>
am missing something (peeks at Adam’s exam paper to copy the answer)<br>
<br>
<br>
* ExplicitNamespaces<br>
<br>
Again, being explicit is good, and it solves this oddity with language<br>
implications not being consistent with language editions (TypeOperators<br>
implies ExplicitNamespaces, but only the former is in gHC2021). In<br>
favor.<br>
<br>
* GADTs<br>
<br>
To me, they are just a normal part of what Haskell is these days. Let’s<br>
declare them so.<br>
<br>
* MonoLocalBinds<br>
<br>
Not an expert, but people say it’s simpler and needed to stay sane with<br>
GADTs. Yes, sometimes annoying (local parser helper etc.), but in those<br>
cases an explicit type signature is probably nice as well. Leaning<br>
towards yes.<br>
<br>
* ImpredicativeTypes<br>
<br>
Trusting Arnaud here, so sure.<br>
<br>
* LambdaCase<br>
<br>
In favor. I have seen code bases making good use of it, and it fits<br>
Haskell with it’s tendency to favor the point-free style. Happy to<br>
include (including the n-ary \cases variant).<br>
<br>
* RoleAnnotations<br>
<br>
Yes! It’s just something you need to build proper abstractions these<br>
days<br>
<br>
* TypeFamilies<br>
<br>
If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as<br>
well. I follow the argument that _if_ there is going to be a breaking<br>
change to their design in the future (evaluation order or something),<br>
it probably needs to be in a separate extension, given the amount of<br>
code out there already, and thus GHC2024 will continue to work. I hope.<br>
(It’s a bit optimistic for type-level stuff, which is not local to one<br>
module).<br>
<br>
<br>
<br>
Hmm, guess I ended up saying yes to all, but with varying levels of<br>
confidence. I trust the collective wisdom of the committee will find<br>
the right selection in the end.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
<br>
<br>
<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>