-- the ones with comments
CUSKs: no
-- ^ according to the guide, this is superseded by StandaloneKindSignatures
ConstrainedClassMethods: yes
-- ^ it is implied by MultiParamTypeClasses anyway
DefaultSignatures: no
-- ^ as Joachim says, this should be succeeded by DerivingVia
-- ^ anyway, this is one required for the writer of the class, so no big deal
DeriveAnyClass: yes
-- ^ I think this makes no harm, and I tend to use deriving (ToJSON, FromJSON)
DerivingVia: yes
-- ^ even though it’s quite recent, I think it’s quite sensible and I don’t foresee many changes to it
DisambiguateRecordFields: no
DuplicateRecordFields: no
-- ^ we seem to still be working on this
FunctionalDependencies: maybe
-- ^ this is a hard one! Not so terrible since it’s only required by the creator of the class, not of the instances
MonadFailDesugaring: yes
-- ^ isn’t this the default nowadays?
MonoLocalBinds: maybe
-- ^ this is implied by GADTs, but otherwise we shouldn’t
MultiWayIf: no
-- ^ still in discussion
NamedWildCards: yes
-- ^ not many people use this, but I think this is the sane default
OverloadedLists: maybe
OverloadedStrings: maybe
-- ^ I would love to see these included, but I agree with the sentiment that they need more work
PartialTypeSignatures: no
-- ^ I really think that partial type signatures should not be accepted by default
QuantifiedConstraints: maybe
-- ^ too early, may want to refine this
ScopedTypeVariables: yes
-- ^ I think this is really well understood and people want it
PatternSynonyms: maybe
-- ^ we are still working out the edges of this

-- these seem simple syntactic extensions
-- many of them bring compatibility with the syntax of Java-like languages
BinaryLiterals: yes
HexFloatLiterals: yes
NegativeLiterals: yes
NumDecimals: yes
NumericUnderscores: yes

-- too early but wouldn’t care to introduce it
StandaloneKindSignatures: maybe
ImportQualifiedPost: maybe

-- don’t know
ForeignFunctionInterface: maybe
GHCForeignImportPrim: maybe
InterruptibleFFI: maybe
LexicalNegation: maybe
NondecreasingIndentation: maybe
PackageImports: maybe
ParallelListComp: maybe
StarIsType: maybe
TransformListComp: maybe
UnliftedFFITypes: maybe
UnliftedNewtypes: maybe
UnicodeSyntax: maybe

-- the rest
AllowAmbiguousTypes: no
ApplicativeDo: no
Arrows: no
BangPatterns: yes
BlockArguments: no
CApiFFI: no
CPP: no
ConstraintKinds: yes
DataKinds: yes
DatatypeContexts: no
DeriveDataTypeable: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveLift: yes
DeriveTraversable: yes
DerivingStrategies: yes
EmptyCase: yes
EmptyDataDecls: yes
EmptyDataDeriving: yes
ExistentialQuantification: yes
ExplicitForAll: yes
ExplicitNamespaces: no
ExtendedDefaultRules: no
FlexibleContexts: yes
FlexibleInstances: yes
GADTSyntax: yes
-- ^ implied by GADTs anyway
GADTs: yes
GeneralisedNewtypeDeriving: yes
ImplicitParams: no
ImpredicativeTypes: no
IncoherentInstances: no
InstanceSigs: yes
KindSignatures: yes
LambdaCase: yes
LiberalTypeSynonyms: no
LinearTypes: no
MagicHash: no
MonadComprehensions: no
MultiParamTypeClasses: yes
NPlusKPatterns: no
NamedFieldPuns: yes
NoImplicitPrelude: no
NoMonomorphismRestriction: yes
NoPatternGuards: no
NoTraditionalRecordSyntax: no
NullaryTypeClasses: yes
OverlappingInstances: no
OverloadedLabels: no
PolyKinds: yes
PostfixOperators: yes
QualifiedDo: no
QuasiQuotes: no
RankNTypes: no
RebindableSyntax: no
RecordWildCards: yes
RecursiveDo: no
RoleAnnotations: no
Safe: no
StandaloneDeriving: yes
StaticPointers: no
Strict: no
StrictData: no
TemplateHaskell: no
TemplateHaskellQuotes: no
Trustworthy: no
TupleSections: yes
TypeApplications: yes
TypeFamilies: yes
TypeFamilyDependencies: no
TypeInType: maybe
TypeOperators: yes
TypeSynonymInstances: yes
UnboxedSums: no
UnboxedTuples: no
UndecidableInstances: no
UndecidableSuperClasses: no
Unsafe: no
ViewPatterns: yes

On 24 Nov 2020 at 10:34:18, Joachim Breitner <mail@joachim-breitner.de> wrote:
Dear Committee,

the requested data (hackage and survey) is in, has been aggregated,
cooked, seasoned and is ready for consumption. 116 extensions are
waiting on your assessment, so time to vote!

## Procedure

Please vote by email to this list, in a response to this thread.

I want to make tallying easy and automatic, and my code will consider
an extension Foo voted for if you write "Foo: yes" on its own line.
This means you can include rationales, write "Foo: maybe" and "Foo: no"
to remind yourself and others that about where you are, and you can
safely quote other’s mails. For example, if you write:

---- begin
example ----

Easy ones:

DeriveFooBar: yes
OverloadedBen: no

These ones are tricky:

ImplicitExceptions: yes
 I know nobody likes that one, but I do.

RandomEvaluationOrder: maybe
 Not sure about this one, here is why…


Richard wrote:
DependentHaskell: yes
Rationale: See my thesis

I’m not convinced yet, tell me more, so
DependentHaskell: maybe

---- end example ----

then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes”
matters, “no”, “maybe” and “later” are all ignored.

I will shortly send my first ballot around. Also see the end of this
mail for a copy’n’paste template.

You can update your vote as often as you want. Please always send your
full votes (I will only consider your latest email). I encourage you to
do that early, e.g. maybe start with a mail where you list the obvious
yes and nos, and keep some at maybe and then refine.

The timeline says first votes should be in within two weeks, and then a
bit more to refine. But the earlier the merrier!

The quota is 8. In particular, if everyone votes (and I hope everyone
will), an extension won’t make it this round if 4 don’t include it.

## Data

Please see
https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data
for the data, including explanations. It is intentionally not sorted by
the data, as the choice of ranking function would already be quite
influencing.

You may want to play around with that data, e.g. sort it by your own
criteria etc. I looked long for an online service where I can upload
the data and allow you to explore it, but then I noticed that that's a
bit stupid, since we all probably can do it best with Haskell.

So I made it easy to load the data into GHCi, see the instructions at
https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md
which allow you, for example, to do this

*Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts)
AllowAmbiguousTypes: 195
CPP: 192
IncoherentInstances: 176
Arrows: 156
Strict: 153
ImplicitParams: 147
UndecidableInstances: 144
OverlappingInstances: 144
Unsafe: 139
TemplateHaskell: 137

Of course, if someone wants to upload the data somewhere and share
that, that's also useful.


Let me know if some of this doesn't quite work for you, and should be
improved. Maybe we need a web form instead of mails?


## PS: Blank ballot

To start, you could copy the following into an email

AllowAmbiguousTypes: maybe
ApplicativeDo: maybe
Arrows: maybe
BangPatterns: maybe
BinaryLiterals: maybe
BlockArguments: maybe
CApiFFI: maybe
CPP: maybe
CUSKs: maybe
ConstrainedClassMethods: maybe
ConstraintKinds: maybe
DataKinds: maybe
DatatypeContexts: maybe
DefaultSignatures: maybe
DeriveAnyClass: maybe
DeriveDataTypeable: maybe
DeriveFoldable: maybe
DeriveFunctor: maybe
DeriveGeneric: maybe
DeriveLift: maybe
DeriveTraversable: maybe
DerivingStrategies: maybe
DerivingVia: maybe
DisambiguateRecordFields: maybe
DuplicateRecordFields: maybe
EmptyCase: maybe
EmptyDataDecls: maybe
EmptyDataDeriving: maybe
ExistentialQuantification: maybe
ExplicitForAll: maybe
ExplicitNamespaces: maybe
ExtendedDefaultRules: maybe
FlexibleContexts: maybe
FlexibleInstances: maybe
ForeignFunctionInterface: maybe
FunctionalDependencies: maybe
GADTSyntax: maybe
GADTs: maybe
GHCForeignImportPrim: maybe
GeneralisedNewtypeDeriving: maybe
HexFloatLiterals: maybe
ImplicitParams: maybe
ImportQualifiedPost: maybe
ImpredicativeTypes: maybe
IncoherentInstances: maybe
InstanceSigs: maybe
InterruptibleFFI: maybe
KindSignatures: maybe
LambdaCase: maybe
LexicalNegation: maybe
LiberalTypeSynonyms: maybe
LinearTypes: maybe
MagicHash: maybe
MonadComprehensions: maybe
MonadFailDesugaring: maybe
MonoLocalBinds: maybe
MultiParamTypeClasses: maybe
MultiWayIf: maybe
NPlusKPatterns: maybe
NamedFieldPuns: maybe
NamedWildCards: maybe
NegativeLiterals: maybe
NoImplicitPrelude: maybe
NoMonomorphismRestriction: maybe
NoPatternGuards: maybe
NoTraditionalRecordSyntax: maybe
NondecreasingIndentation: maybe
NullaryTypeClasses: maybe
NumDecimals: maybe
NumericUnderscores: maybe
OverlappingInstances: maybe
OverloadedLabels: maybe
OverloadedLists: maybe
OverloadedStrings: maybe
PackageImports: maybe
ParallelListComp: maybe
PartialTypeSignatures: maybe
PatternSynonyms: maybe
PolyKinds: maybe
PostfixOperators: maybe
QualifiedDo: maybe
QuantifiedConstraints: maybe
QuasiQuotes: maybe
RankNTypes: maybe
RebindableSyntax: maybe
RecordWildCards: maybe
RecursiveDo: maybe
RoleAnnotations: maybe
Safe: maybe
ScopedTypeVariables: maybe
StandaloneDeriving: maybe
StandaloneKindSignatures: maybe
StarIsType: maybe
StaticPointers: maybe
Strict: maybe
StrictData: maybe
TemplateHaskell: maybe
TemplateHaskellQuotes: maybe
TransformListComp: maybe
Trustworthy: maybe
TupleSections: maybe
TypeApplications: maybe
TypeFamilies: maybe
TypeFamilyDependencies: maybe
TypeInType: maybe
TypeOperators: maybe
TypeSynonymInstances: maybe
UnboxedSums: maybe
UnboxedTuples: maybe
UndecidableInstances: maybe
UndecidableSuperClasses: maybe
UnicodeSyntax: maybe
UnliftedFFITypes: maybe
UnliftedNewtypes: maybe
Unsafe: maybe
ViewPatterns: maybe




--
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