[ghc-steering-committee] GHC2024 committee deliberation

[Simon Peyton Jones]

>
> * 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 at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231121/4fbc9b76/attachment.html>