New votes (as of 7 December), I’ve changed ViewPatterns to ’no’.
-- 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: no
-- ^ too recent
DisambiguateRecordFields: no
DuplicateRecordFields: no
-- ^ we seem to still be working on this
FunctionalDependencies: yes
-- ^ this is a hard one! I lean towards yes because they are guarded by its
own syntax
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: no
-- ^ 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
BlockArguments: no
-- ^ too early
ViewPatterns: no
-- ^ the are better alternatives being proposed
-- 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: no
LexicalNegation: maybe
NondecreasingIndentation: maybe
PackageImports: no
ParallelListComp: no
TransformListComp: no
UnliftedFFITypes: no
UnliftedNewtypes: no
-- the rest
AllowAmbiguousTypes: no
ApplicativeDo: no
Arrows: no
BangPatterns: yes
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
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
On 5 Dec 2020 at 21:42:22, Alejandro Serrano Mena
My new votes (as of 5 December):
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: no -- ^ too recent DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: yes -- ^ this is a hard one! I lean towards yes because they are guarded by its own syntax 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 BlockArguments: no -- ^ too early
-- 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 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 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