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

Spiwack, Arnaud arnaud.spiwack at tweag.io
Thu Dec 3 10:52:48 UTC 2020


Orthogonally, we probably want to wait a release or two before rolling a
new extension into the default. So maybe it's a bit early for
UnliftedNewtypes.

On Thu, Dec 3, 2020 at 11:48 AM Simon Marlow <marlowsd at gmail.com> wrote:

>
>
> On Thu, 3 Dec 2020 at 08:51, Joachim Breitner <mail at 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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/1d62d3e5/attachment-0001.html>


More information about the ghc-steering-committee mailing list