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

[Alejandro Serrano Mena]

 Thanks everybody for an illuminating discussion about DeriveAnyClass. I
was not aware of the dark corners of the extension (and actually, now I
find it weird that GHC itself suggests that extension!). Here are my
updated votes; apart from a ’No’ to DeriveAnyClass I’ve updated my votes of
StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’.

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

-- 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 30 Nov 2020 at 18:33:55, Richard Eisenberg <rae at richarde.dev> wrote:

> I also adopted Iavor's very helpful categorization.
>
> I have not given any motivations below, as it's too difficult to read
> everyone's motivations inline. Instead, I give several varieties of "no"
> votes. Let's debate when someone disagrees with me. (To be clear: "obscure"
> just means that someone should manually opt in, not that the feature is
> really obscure.)
>
>
> *Module System=============*
>
> ImportQualifiedPost: yes
> PackageImports: obscure
> NoImplicitPrelude: breaking
>
>
> *Notation========*
>
> BlockArguments: yes
> MultiWayIf: might change
> LambdaCase: might change
> BinaryLiterals: yes
> HexFloatLiterals: yes
> NumericUnderscores: yes
> NumDecimals: yes
> OverloadedStrings: bad for beginners
> OverloadedLists: bad for beginners
> OverloadedLabels: obscure
> EmptyCase: yes
> PostfixOperators: yes
> LexicalNegation: yes
> UnicodeSyntax: yes
> NegativeLiterals: superseded
> TupleSections: yes
> ImplicitParams: obscure
> ParallelListComp: yes
> RecursiveDo: obscure
> TransformListComp: obscure
> Arrows: obscure
> ApplicativeDo: breaking
> QualifiedDo: too fresh
> MonadComprehensions: bad for beginners
> NondecreasingIndentation: obscure
> RebindableSyntax: breaking
> ExplicitNamespaces: yes
>
>
>
> *Data Types==========*
> DatatypeContexts: no
> ExistentialQuantification: yes
> EmptyDataDecls: yes
> RoleAnnotations: yes
> StrictData: breaking
> GADTSyntax: yes
> GADTs: obscure
>
>
> *Patterns and Guards===================*
>
> BangPatterns: yes
> ViewPatterns: yes
> PatternSynonyms: too fresh
> NoPatternGuards: breaking
> NPlusKPatterns: deprecated
>
>
> *Records=======*
>
> NamedFieldPuns: yes
> RecordWildCards: confusing
> DisambiguateRecordFields: yes
> DuplicateRecordFields: might change
> NoTraditionalRecordSyntax: no
>
>
> *Deriving=======*
>
> DeriveGeneric: yes
> DeriveLift: yes
> DeriveDataTypeable: yes
> EmptyDataDeriving: yes
> StandaloneDeriving: yes
> DeriveFunctor: yes
> DeriveFoldable: yes
> DeriveTraversable: yes
> DerivingStrategies: yes
> DerivingVia: yes
> GeneralisedNewtypeDeriving: yes
> DeriveAnyClass: dangerous
>
>
> *Class System============*
>
> MultiParamTypeClasses: yes
> NullaryTypeClasses: superseded
> ConstraintKinds: yes
> TypeSynonymInstances: yes
> FlexibleInstances: yes
> FlexibleContexts: yes
> ConstrainedClassMethods: yes
> DefaultSignatures: yes
> InstanceSigs: yes
> ExtendedDefaultRules: might change
> FunctionalDependencies: obscure
> QuantifiedConstraints: too fresh
> UndecidableInstances: dangerous
> IncoherentInstances: dangerous
> UndecidableSuperClasses: dangerous
> OverlappingInstances: superseded
>
> Types
> *=====*
>
> RankNTypes: yes
> StandaloneKindSignatures: yes
> KindSignatures: yes
> LiberalTypeSynonyms: confusing
> ScopedTypeVariables: might change
> ExplicitForAll: yes
> AllowAmbiguousTypes: dangerous
> ImpredicativeTypes: too fresh
> MonoLocalBinds: breaking
> NoMonomorphismRestriction: debate!
> PartialTypeSignatures: obscure
> NamedWildCards: yes
> LinearTypes: too fresh
> TypeApplications: yes
> PolyKinds: yes
> TypeOperators: yes
> StarIsType: deprecated
> TypeFamilies: obscure
> TypeFamilyDependencies: obscure
> DataKinds: might change
>
>
> *FFI===*
>
> ForeignFunctionInterface: obscure
> CApiFFI: obscure
> GHCForeignImportPrim: obscure
> InterruptibleFFI: obscure
> UnliftedFFITypes: obscure
> StaticPointers: obscure
>
>
> *Low Level=========*
>
> UnboxedSums: obscure
> UnboxedTuples: obscure
> MagicHash: obscure
> UnliftedNewtypes: yes
>
>
> *Macros======*
>
> CPP: obscure
> TemplateHaskell: TH
> TemplateHaskellQuotes: yes
> QuasiQuotes: TH
>
>
>
> *Other=====*
>
> Unsafe: no
> Safe: no
> Trustworthy: no
> Strict: no
>
>
> *Obsolete/Deprecated===================*
>
> CUSKs: no
> TypeInType: no
> MonadFailDesugaring: maybe
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/93c15520/attachment-0001.html>