<div dir="ltr"><div>Updated votes, resolving all my maybes:<br></div><div><br></div><div>Delta:<br><br> * yes to NamedWildCards *and* PartialTypeSignatures (these are<br> actually really useful and unless someone tells me otherwise I<br> don't know any reason why the language with these is less<br> principled than without. I would also -Wno-partial-type-signatures<br> by default if that was in scope for GHC2021)<br> * yes to TypeApplications (sure, why not)<br> * all other maybes -> no (mainly just being conservative, we can<br> reconsider for GHC2022 any that miss out)<br><br>## Uncontroversial extensions<br><br>BangPatterns: yes<br>BinaryLiterals: yes<br>DataKinds: yes<br>DeriveDataTypeable: yes<br>DeriveGeneric: yes<br>EmptyCase: yes<br>ExistentialQuantification: yes<br>FlexibleContexts: yes<br>FlexibleInstances: yes<br>GADTs: yes<br>GeneralisedNewtypeDeriving: yes<br>LambdaCase: yes<br>MultiParamTypeClasses: yes<br>MultiWayIf: yes<br>NoMonomorphismRestriction: yes<br>OverloadedStrings: yes<br>PatternSynonyms: yes<br>RankNTypes: yes<br>RecordWildCards: yes<br>ScopedTypeVariables: yes<br>StandaloneDeriving: yes<br>TupleSections: yes<br>TypeFamilies: yes<br>TypeSynonymInstances: yes<br>NondecreasingIndentation: yes<br>ConstrainedClassMethods: yes<br>ConstraintKinds: yes<br>DefaultSignatures: yes<br>DeriveFoldable: yes<br>DeriveFunctor: yes<br>DeriveTraversable: yes<br>EmptyDataDecls: yes<br>EmptyDataDeriving: yes<br>HexFloatLiterals: yes<br>ImportQualifiedPost: yes<br>InstanceSigs: yes<br>KindSignatures: yes<br>LiberalTypeSynonyms: yes<br>NamedFieldPuns: yes<br> (I don't personally like this, but I can't justify having<br> RecordWildcards but not having this)<br>NegativeLiterals: yes<br>NumDecimals: yes<br>PolyKinds: yes<br>PostfixOperators: yes<br>UnicodeSyntax: yes<br> (but only the language extension, not the UI changes)<br><br>## Extensions that are implied by others, or are irrelevant:<br><br>GADTSyntax: yes<br>ExplicitForAll: yes<br>MonadFailDesugaring: irrelevant<br>MonoLocalBinds: yes<br><br>## Extensions that are deprecated or exist for legacy reasons:<br><br>DatatypeContexts: no<br>NPlusKPatterns: no<br>CUSKs: no<br>NoPatternGuards: no<br>ForeignFunctionInterface: yes<br> (already implied by Haskell2010, why do we have this but<br> NoPatternGuards?)<br>NullaryTypeClasses: no<br>OverlappingInstances: no<br>IncoherentInstances: no<br>TypeInType: no<br><br>## No to extensions that are too new to include in GHC2021:<br><br>QualifiedDo: no<br>LinearTypes: no<br>BlockArguments: no<br>LexicalNegation: no<br>QuantifiedConstraints: no<br>StandaloneKindSignatures: yes<br> (changed to yes because it's needed to replace CUSKs)<br>StarIsType: yes<br> (changed to yes following discussion)<br><br>## No to extensions that are opt-in by design:<br><br>ApplicativeDo: no<br> (can lead to non-deterministic behaviour with non-rule-abiding<br> Applicative instances)<br>PackageImports: no<br>CPP: no<br>DeriveLift: no<br> (only makes sense with TemplateHaskell, which is opt-in)<br>TemplateHaskell: no<br>TemplateHaskellQuotes: no<br>QuasiQuotes: no<br>RebindableSyntax: no<br>Safe: no<br>Strict: no<br>StrictData: no<br>Trustworthy: no<br>Unsafe: no<br>ExtendedDefaultRules: no<br>NoImplicitPrelude: no<br><br>## No to unsafe extensions:<br><br>UndecidableInstances: no<br>UndecidableSuperClasses: no<br><br>## No to low-level extensions, not intended to be on by default:<br><br>UnboxedTuples: no<br>UnboxedSums: no<br>MagicHash: no<br>UnliftedFFITypes: no<br>UnliftedNewtypes: no<br>GHCForeignImportPrim: no<br>InterruptibleFFI: no<br><br>## No to record-related extensions<br><br>Records are in flux, let's not do any of this in GHC2021.<br><br>DisambiguateRecordFields: no<br>DuplicateRecordFields: no<br>NoTraditionalRecordSyntax: no<br>OverloadedLabels: no<br><br>## The rest<br><br>That leaves some tricky ones, I'm putting all these as "no" or<br>"maybe"; we could conservatively just say "no" to all of them.<br><br>I'm voting NO on these:<br><br>Arrows: no<br> (not widely used)<br>ImplicitParams: no<br> (not widely used; questionable semantics; functionality available<br> with reflection package)<br>ImpredicativeTypes: no<br> (I don't think we want this on by default, right?)<br>ParallelListComp: no<br> (not widely used, most uses are covered by zip)<br>StaticPointers: no<br> (quite a niche extension, only really useful with Distributed Haskell)<br>TransformListComp: no<br> (not widely used)<br>ViewPatterns: no<br> (not widely used, and in my opinion not a good design)<br>DeriveAnyClass: no<br> (see discussion on the mailing list)<br><br>Undecided (later resolved):<br><br>AllowAmbiguousTypes: no<br>TypeApplications: yes<br>CApiFFI: no<br> (harmless, but a bit niche)<br>DerivingVia: no<br> (not very widely-used, quite new)<br>DerivingStrategies: no<br> (not very widely-used, quite new)<br>FunctionalDependencies: no<br> (slightly inclined to "no", given the overlap<br> with TypeFamilies and the lack of widespread usage)<br>ExplicitNamespaces: no<br> (might change, so defer?)<br>MonadComprehensions: no<br> (does this make error messages worse?)<br>NamedWildCards: yes<br>NumericUnderscores: no<br>OverloadedLists: no<br> (impact on error messages?)<br>PartialTypeSignatures: yes<br>RecursiveDo: no<br> (but introduced by a keyword so relatively harmless)<br>RoleAnnotations: no<br> (not widely used, but when you need it you need it)<br>TypeFamilyDependencies: no<br> (not widely used, but when you need it you need it)<br>TypeOperators: no<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 7 Dec 2020 at 18:17, 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">Dear Committe,<br>
<br>
it’s been two weeks since we started voting. We are still short one<br>
vote (Cale, release the suspsense!). But also, there are still plenty<br>
of “maybes” in your vote. I encourage you to change them to yes or no<br>
(at least for those extensions that are near the edge), so that we have<br>
more clarity on which extensions are actually worth spending emails on.<br>
<br>
As always, the table<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data</a><br>
has the current data. (And even even got community contributions to<br>
improve its readability. Yay!)<br>
<br>
We discussed many extensions on (and I might have missed some):<br>
<br>
* The innnocence of PostfixOperators was pointed out, and widely<br>
appreciated<br>
* Joachim pleads for UnicodeSyntax<br>
* InstanceSigs worries seems to have been addressed, it’s on its way<br>
in<br>
* Whether OverloadedString is harmless enough.<br>
* Whether ViewPatterns are good enough (given that alternative ideas <br>
exist)<br>
* That ForeignFunctionInterfaces is actually part of Haskell2010<br>
* That this isn’t quite the right time to ditch StarIsType<br>
* CUSKs vs. StandaloneKindSignatures<br>
* BlockArguments is liked by some, but may be too new<br>
* GADTs were advocated for a lot, but also a bit against, so not <br>
uncontroversial<br>
* Same with ExistentialQuantification<br>
* PolyKinds were advocated for (and got many votes)<br>
* ScopedTypeVariables is wanted on by default by some,<br>
despite the fact that nobody believes it’s the last<br>
word on that design corner. Alejandro argues that it’s<br>
ok to include it even if it will change in GHC202X again,<br>
but elsewhere SPJ says that GHC2021 should only include extensions<br>
we have reason to hope are stable and stay around .<br>
* Arnaud wonders about the hesitation to include <br>
FunctionalDependencies<br>
<br>
<br>
Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go<br>
in no matter how Cale votes:<br>
<br>
BangPatterns, BinaryLiterals, ConstrainedClassMethods,<br>
ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor,<br>
DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase,<br>
EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts,<br>
FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving,<br>
HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures,<br>
MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores,<br>
PolyKinds, PostfixOperators, RankNTypes, StandaloneDeriving,<br>
StarIsType, TypeApplications, TypeOperators, TypeSynonymInstances<br>
<br>
The following have 7 votes, which is the quorum based on 10 ballots:<br>
<br>
ExistentialQuantification, ForeignFunctionInterface, MonoLocalBinds,<br>
NegativeLiterals, RecordWildCards, StandaloneKindSignatures,<br>
TypeFamilies<br>
<br>
And these are one vote short:<br>
<br>
DataKinds, DerivingStrategies, GADTs, NamedWildCards,<br>
ScopedTypeVariables, TupleSections, UnicodeSyntax, ViewPatterns<br>
<br>
<br>
Not sure how useful the list of symmetric difference report is, but<br>
here it is:<br>
<br>
alejandro<br>
would miss:<br>
DataKinds, DerivingStrategies, FunctionalDependencies, GADTs,<br>
LambdaCase, MonadFailDesugaring, NamedWildCards,<br>
NoMonomorphismRestriction, NullaryTypeClasses, NumDecimals,<br>
OverloadedLists, OverloadedStrings, ScopedTypeVariables, TupleSections,<br>
UnicodeSyntax, ViewPatterns<br>
doesn’t want:<br>
none!<br>
<br>
arnaud<br>
would miss:<br>
Arrows, DerivingStrategies, ExplicitNamespaces, FunctionalDependencies,<br>
GADTs, MonadFailDesugaring, PartialTypeSignatures,<br>
TypeFamilyDependencies, ViewPatterns<br>
doesn’t want:<br>
ExistentialQuantification, ImportQualifiedPost, InstanceSigs,<br>
NamedFieldPuns, PolyKinds, RankNTypes, RecordWildCards,<br>
StandaloneKindSignatures, TypeSynonymInstances<br>
<br>
eric<br>
would miss:<br>
DataKinds, DefaultSignatures, DisambiguateRecordFields,<br>
ExplicitNamespaces, FunctionalDependencies, GADTs, MonadFailDesugaring,<br>
NamedWildCards, OverloadedLists, OverloadedStrings,<br>
PartialTypeSignatures, PatternSynonyms, RoleAnnotations,<br>
ScopedTypeVariables, TypeFamilyDependencies<br>
doesn’t want:<br>
EmptyDataDeriving, ForeignFunctionInterface<br>
<br>
iavor<br>
would miss:<br>
BlockArguments, CApiFFI, MultiWayIf, NoMonomorphismRestriction,<br>
NullaryTypeClasses, ParallelListComp, RecursiveDo, UnicodeSyntax,<br>
UnliftedNewtypes<br>
doesn’t want:<br>
ConstrainedClassMethods, EmptyCase, ExplicitForAll, GADTSyntax,<br>
GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures,<br>
MonoLocalBinds, NegativeLiterals, PolyKinds, StandaloneKindSignatures,<br>
StarIsType, TypeApplications, TypeFamilies, TypeOperators<br>
<br>
joachim<br>
would miss:<br>
DataKinds, DerivingStrategies, DerivingVia, LambdaCase, NamedWildCards,<br>
NondecreasingIndentation, RoleAnnotations, TupleSections,<br>
UnicodeSyntax, UnliftedFFITypes, UnliftedNewtypes<br>
doesn’t want:<br>
ConstrainedClassMethods, ExistentialQuantification,<br>
TypeSynonymInstances<br>
<br>
richard<br>
would miss:<br>
BlockArguments, DefaultSignatures, DerivingStrategies, DerivingVia,<br>
DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation,<br>
NamedWildCards, NumDecimals, ParallelListComp, RoleAnnotations,<br>
TemplateHaskellQuotes, TupleSections, UnicodeSyntax, UnliftedNewtypes,<br>
ViewPatterns<br>
doesn’t want:<br>
MonoLocalBinds, NegativeLiterals, RecordWildCards, TypeFamilies<br>
<br>
simonm<br>
would miss:<br>
DataKinds, DefaultSignatures, GADTs, LambdaCase, LiberalTypeSynonyms,<br>
MultiWayIf, NoMonomorphismRestriction, NondecreasingIndentation,<br>
NumDecimals, OverloadedStrings, PatternSynonyms, ScopedTypeVariables,<br>
TupleSections, UnicodeSyntax<br>
doesn’t want:<br>
DeriveLift, NumericUnderscores, TypeApplications, TypeOperators<br>
<br>
spj<br>
would miss:<br>
NoMonomorphismRestriction, NullaryTypeClasses, OverloadedLists,<br>
OverloadedStrings, ParallelListComp, RecursiveDo, RoleAnnotations,<br>
ScopedTypeVariables, ViewPatterns<br>
doesn’t want:<br>
ForeignFunctionInterface, GeneralisedNewtypeDeriving, NegativeLiterals,<br>
RecordWildCards, TypeFamilies<br>
<br>
tom<br>
would miss:<br>
BlockArguments, DataKinds, DefaultSignatures, DerivingStrategies,<br>
DerivingVia, DisambiguateRecordFields, DuplicateRecordFields,<br>
ExplicitNamespaces, FunctionalDependencies, GADTs, LambdaCase,<br>
LexicalNegation, LiberalTypeSynonyms, MagicHash, MultiWayIf,<br>
NamedWildCards, NullaryTypeClasses, NumDecimals, PackageImports,<br>
ParallelListComp, QuasiQuotes, RoleAnnotations, ScopedTypeVariables,<br>
TemplateHaskell, TemplateHaskellQuotes, TupleSections,<br>
TypeFamilyDependencies, UnboxedSums, UnboxedTuples, UnicodeSyntax,<br>
UnliftedNewtypes, ViewPatterns<br>
doesn’t want:<br>
ForeignFunctionInterface, MonoLocalBinds, StarIsType<br>
<br>
vitaly<br>
would miss:<br>
DataKinds, DerivingStrategies, DerivingVia, GADTs, LambdaCase,<br>
MonadFailDesugaring, NamedWildCards, OverloadedLists,<br>
OverloadedStrings, ScopedTypeVariables, TupleSections, ViewPatterns<br>
doesn’t want:<br>
ExistentialQuantification, StandaloneKindSignatures<br>
<br>
Cheers,<br>
Joachim<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>
_______________________________________________<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>