* 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
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/proposal... (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