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

Alejandro Serrano Mena trupill at gmail.com
Mon Dec 7 20:16:36 UTC 2020


 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 <trupill at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/75b2668d/attachment-0001.html>


More information about the ghc-steering-committee mailing list