On Thu, 3 Dec 2020 at 08:51, Joachim Breitner <mail@joachim-breitner.de> wrote:

UnliftedNewtypes: yes
  -- ^ or is there something wrong with that?

I took the view that everything related to unboxed and unlifted types is "GHC-specific extension" territory, and unlikely to ever be in a Haskell language standard, so we probably shouldn't have these extensions on by default. That might be a somewhat outdated viewpoint these days, but still it's at least something we can apply consistently. So from my vote I lumped all these together:

> UnboxedTuples: no
> UnboxedSums: no
> MagicHash: no
> UnliftedFFITypes: no
> UnliftedNewtypes: no

Cheers

Simon

 

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@joachim-breitner.de
  http://www.joachim-breitner.de/


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee