Just for the record, I voted "yes" on view patterns... :)
On Sun, Dec 6, 2020 at 2:32 PM Joachim Breitner
Hi,
as the week ends, a quick update summarizing various inline “I’m convinced” vote updates from me:
PolyKinds: yes -- ^ Got convinced by Richard
CUSKs: no StandaloneKindSignatures: yes -- ^ A change from Haskell2010, but in a corner where the target audience probably prefers progress
MonomorphismRestriction: yes -- ^ Is in Haskell2010, I have no reason to change that
Controversial and/or pleaded against:
ViewPatterns: no (convinced by Iavor) GADTs: no (too controversial) ExistentialQuantification: no (convinced by Richard)
I continue 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 at least those who have this on maybe (Arnaud, Iavor and SPJ) might be swayed by that clarification.
Unchanged votes follow:
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
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 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 GeneralisedNewtypeDeriving: yes KindSignatures: yes LambdaCase: yes MultiParamTypeClasses: yes RankNTypes: yes StandaloneDeriving: yes TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeOperators: 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 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 GHCForeignImportPrim: maybe LexicalNegation: maybe -- ^ Unsure about the maturity of the whitespace sensitiviy trend
-- 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