On Thu, 3 Dec 2020 at 08:51, Joachim Breitner
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