[ghc-steering-committee] GHC2024 committee deliberation

[Joachim Breitner]

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 at joachim-breitner.de
  http://www.joachim-breitner.de/