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

[Joachim Breitner]

Hi,

thanks all for various inputs, I’ll update my votes as follows:

PostfixOperators: yes

NamedWildCards: yes
 -- ^ Following Alejandro here: Seems safe and maybe more useful if
      it can be used without friction.

ForeignFunctionInterface: yes
 -- ^ As Simon M points out, this is part
of Haskell2010, and
      was put on the ballet in this form (rather
than 
      NoForeignFunctionInterface) by accident. I do not want to
remove
      anything that’s there (and I assume that nobody does
without
      making that very explicit).

MonoLocalBinds: yes
 -- ^ Not an expert, but it’s probably nice if turning on GADTs or
      TypeFamilies (if they don't make it on their own) don’t change
      seemingly unrelated part of the code.

ImportQualifiedPost: yes
 -- ^ Personally don’t care a lot about it, but I don’t want to veto it
      either, so following Iavor here.

HexFloatLiterals: yes
 -- ^ More syntax for literals doesn’t hurt


I’d also like to advocate for UnicodeSyntax, with the implied provision
that -XGHC2021 will make GHC accept Unicode syntax, but without writing
error messages using it (i.e. no implied -fprint-unicode-syntax).
I hope that this sways at least least those who have this on “maybe”
(Alejandro, Arnaud, Iavor and SPJ).


Unchanged votes follow:


Let’s first get all those out of the way that are too contentions
according to the data (with 2*no>yes votes):

My starting point here was:
*Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts,
survey_no > 10, survey_no * 2 > survey_yes ]

And that gave me the following:

AllowAmbiguousTypes: no
ApplicativeDo: no
Arrows: no
BlockArguments: no
CApiFFI: no
CPP: no
ConstrainedClassMethods: no
DatatypeContexts: no
DisambiguateRecordFields: no
DuplicateRecordFields: no
ExplicitNamespaces: no
ExtendedDefaultRules: no
ImplicitParams: no
ImpredicativeTypes: no
IncoherentInstances: no
InterruptibleFFI: no
LiberalTypeSynonyms: no
MagicHash: no
MonadComprehensions: no
NPlusKPatterns: no
NoImplicitPrelude: no
NoMonomorphismRestriction: no
NoPatternGuards: no
NoTraditionalRecordSyntax: no
NullaryTypeClasses: no
NumDecimals: no
 -- ^ Unsure about this one
OverlappingInstances: no
OverloadedLabels: no
OverloadedLists: no
PackageImports: no
ParallelListComp: no
PartialTypeSignatures: no
 -- ^ Unsure about this one, but trusting the crowd until convinced 
   
otherwise
QuantifiedConstraints: no
QuasiQuotes: no
RebindableSyntax: no
RecursiveDo: no
 -- ^ I like that one. But probably not widespread enough.
StaticPointers: no
Strict: no
StrictData: no
TemplateHaskell: no
TemplateHaskellQuotes: no
TransformListComp: no
Trustworthy: no
TypeFamilyDependencies: no
TypeInType: no
TypeSynonymInstances: no
UnboxedSums: no
UnboxedTuples: no
UndecidableInstances: no
UndecidableSuperClasses: no
Unsafe: no

Actually, some of them I disagree with, and believe they are safe to
turn on by default, and would be happy to, with sufficient committee
support:

NegativeLiterals: yes
RoleAnnotations: yes
UnicodeSyntax: yes
  -- ^ I ❤ unicode
UnliftedNewtypes: yes
  -- ^ or is there something wrong with that?

Now to those with at least 20% popularity:

*Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, not
(survey_no > 10 && survey_no * 2 > survey_yes), 5 * survey_yes >
survey_total  ]

These I happily go with, until I learn otherwise:

BangPatterns: yes
ConstraintKinds: yes
DataKinds: yes
DeriveDataTypeable: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveTraversable: yes
DerivingStrategies: yes
DerivingVia: yes
FlexibleContexts: yes
FlexibleInstances: yes
GADTs: yes
GeneralisedNewtypeDeriving: yes
KindSignatures: yes
LambdaCase: yes
MultiParamTypeClasses: yes
RankNTypes: yes
StandaloneDeriving: yes
TupleSections: yes
TypeApplications: yes
TypeFamilies: yes
TypeOperators: yes
ViewPatterns: yes

There are some where I disagree with the crowd:

ScopedTypeVariables: no
  -- ^ Too much of a kitchen sink, some edges are rough, and some of 
       its semantics (“bind type signatures unless in scope”) are being
       questioned.

       If we had the plain PatternSignatures as a separate extension,
       I’d vote that in though. If ScopedTypeVariables doesn't make it
       this round, I will revive #119 to get that.

OverloadedStrings: no
  -- ^ yes, has many fans. But I believe that many might actuall
       use that although what they really want is a monomorphic

         "foo" :: Text

       and I wonder if there is a way to give them that.

       Also, some report that too much polymorphism can hurt, e.g. in

         is_vowel c = c `elem` "aeiou"

       Three is also 12% Aloofness and 12% Contentionsness, which are
       not to be dismissed.

       So I am inclined to leave this out, for this round at least.

MultiWayIf: no
  -- ^ in light of discussion around a multi-case, maybe premature


The remaining ones,
*Main> putStr $ unlines [ ext ++ ": yes" | E{..} <- M.elems exts, not
(survey_no > 10 && survey_no * 2 > survey_yes), not (5 * survey_yes >
survey_total)  ]

Kinda clear:

BinaryLiterals: yes
DeriveLift: yes
EmptyCase: yes
EmptyDataDecls: yes
EmptyDataDeriving: yes
ExistentialQuantification: yes
  -- ^ Or is anything wrong with that?
ExplicitForAll: yes
GADTSyntax: yes
  -- ^ In case GADTs don’t make it
InstanceSigs: yes
NamedFieldPuns: yes
NondecreasingIndentation: yes
  -- ^ It’s Haskell98
and the current default(!), but not Haskell2010?
NumericUnderscores: yes
RecordWildCards: yes
UnliftedFFITypes: yes
StarIsType: yes
  -- ^ It’s the default now. Probably too early to turn off?

DefaultSignatures: no
  -- ^ Deriving via is probably preferrable these days
DeriveAnyClass: no
LinearTypes: no
PatternSynonyms: no
  -- ^ I like them, but maybe a bit too early
MonadFailDesugaring: no
  -- ^ This extension is temporary, and will be deprecated in a future
release.
QualifiedDo: no
Safe: no

No expert on these, will read your rationales:

FunctionalDependencies: maybe
StandaloneKindSignatures: maybe
CUSKs: maybe
GHCForeignImportPrim: maybe
LexicalNegation: maybe
  -- ^ Unsure about the maturity of the whitespace sensitiviy trend
PolyKinds: maybe
  -- ^ Does it even make sense to vote on this?


Quite a long list! Surely the next years will be easier.


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/