* MonoLocalBinds

Not an expert, but people say it’s simpler and needed to stay sane with
GADTs. Yes, sometimes annoying (local parser helper etc.), but in those
cases an explicit type signature is probably nice as well. Leaning
towards yes.

I agree.  But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds.

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.

You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story.

Simon

On Tue, 21 Nov 2023 at 17:18, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

thanks for pushing more and well-justified proposals.

Allow me to collect my thoughts on the individual additions proposed at
https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst
(generally, I’m guess I'm an inclusionist here)

* DataKinds and TypeData

Leaning towards yes for DataKinds, unsure for TypeData, and will bow in
if this turns out to be contentious. It feels like a step in the right
direction, but I am not a heavy user.

* DerivingStrategies

Being more explicit seems to be useful, e.g. with documentation, and it
certainly doesn’t hurt. In favor.

* DisambiguateRecordFields

Small quality-of-life improvement, so sure, why not. In favor, unless I
am missing something (peeks at Adam’s exam paper to copy the answer)


* ExplicitNamespaces

Again, being explicit is good, and it solves this oddity with language
implications not being consistent with language editions (TypeOperators
implies ExplicitNamespaces, but only the former is in gHC2021). In
favor.

* GADTs

To me, they are just a normal part of what Haskell is these days. Let’s
declare them so.

* MonoLocalBinds

Not an expert, but people say it’s simpler and needed to stay sane with
GADTs. Yes, sometimes annoying (local parser helper etc.), but in those
cases an explicit type signature is probably nice as well. Leaning
towards yes.

* ImpredicativeTypes

Trusting Arnaud here, so sure.

* LambdaCase

In favor. I have seen code bases making good use of it, and it fits
Haskell with it’s tendency to favor the point-free style. Happy to
include (including the n-ary \cases variant).

* RoleAnnotations

Yes! It’s just something you need to build proper abstractions these
days

* TypeFamilies

If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as
well. I follow the argument that _if_ there is going to be a breaking
change to their design in the future (evaluation order or something),
it probably needs to be in a separate extension, given the amount of
code out there already, and thus GHC2024 will continue to work. I hope.
(It’s a bit optimistic for type-level stuff, which is not local to one
module).



Hmm, guess I ended up saying yes to all, but with varying levels of
confidence. I trust the collective wisdom of the committee will find
the right selection in the end.

Cheers,
Joachim








--
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee