[ghc-steering-committee] #380 GHC2021: Voting starts

[Alejandro Serrano Mena]

 Here are my new votes, after several discussions, and reading a bit about
defaults (like for StarIsType) in the User Guide.

-- 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: no
-- ^ given our discussion
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: yes
-- ^ this is implied by GADTs and TypeFamilies
MultiWayIf: no
-- ^ still in discussion
NamedWildCards: yes
-- ^ not many people use this, but I think this is the sane default
OverloadedLists: yes
OverloadedStrings: yes
-- ^ 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: no
-- ^ too early
ScopedTypeVariables: yes
-- ^ I think this is really well understood and people want it
PatternSynonyms: maybe
-- ^ we are still working out the edges of this
ForeignFunctionInterface: yes
RankNTypes: yes
UnicodeSyntax: yes
-- ^ following Joachim’s suggestion: enable this for syntax but *not* for
error messages
TypeInType: maybe
-- ^ this simply implies PolyKinds, DataKinds, KindSignatures, according to
the documentation
StarIsType: yes
-- ^ this is on by default, and I think it would be very confusing to stop
treating “*” different from “Type” as this moment

-- 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: yes
ImportQualifiedPost: yes

-- don’t know
GHCForeignImportPrim: maybe
InterruptibleFFI: maybe
LexicalNegation: maybe
NondecreasingIndentation: maybe
PackageImports: maybe
ParallelListComp: maybe
TransformListComp: maybe
UnliftedFFITypes: maybe
UnliftedNewtypes: 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
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
TypeOperators: yes
TypeSynonymInstances: yes
UnboxedSums: no
UnboxedTuples: no
UndecidableInstances: no
UndecidableSuperClasses: no
Unsafe: no
ViewPatterns: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/06490c38/attachment-0001.html>