<div dir="ltr"><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 3, 2020 at 11:48 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Dec 2020 at 08:51, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
UnliftedNewtypes: yes<br>
  -- ^ or is there something wrong with that?<br>
<br></blockquote><div><br></div><div>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:</div><div><br></div><div>> UnboxedTuples: no<br>> UnboxedSums: no<br>> MagicHash: no<br>> UnliftedFFITypes: no<br>> UnliftedNewtypes: no<br></div></div><div class="gmail_quote"><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now to those with at least 20% popularity:<br>
<br>
*Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, not<br>
(survey_no > 10 && survey_no * 2 > survey_yes), 5 * survey_yes ><br>
survey_total  ]<br>
<br>
These I happily go with, until I learn otherwise:<br>
<br>
BangPatterns: yes<br>
ConstraintKinds: yes<br>
DataKinds: yes<br>
DeriveDataTypeable: yes<br>
DeriveFoldable: yes<br>
DeriveFunctor: yes<br>
DeriveGeneric: yes<br>
DeriveTraversable: yes<br>
DerivingStrategies: yes<br>
DerivingVia: yes<br>
FlexibleContexts: yes<br>
FlexibleInstances: yes<br>
GADTs: yes<br>
GeneralisedNewtypeDeriving: yes<br>
KindSignatures: yes<br>
LambdaCase: yes<br>
MultiParamTypeClasses: yes<br>
RankNTypes: yes<br>
StandaloneDeriving: yes<br>
TupleSections: yes<br>
TypeApplications: yes<br>
TypeFamilies: yes<br>
TypeOperators: yes<br>
ViewPatterns: yes<br>
<br>
There are some where I disagree with the crowd:<br>
<br>
ScopedTypeVariables: no<br>
  -- ^ Too much of a kitchen sink, some edges are rough, and some of <br>
       its semantics (“bind type signatures unless in scope”) are being<br>
       questioned.<br>
<br>
       If we had the plain PatternSignatures as a separate extension,<br>
       I’d vote that in though. If ScopedTypeVariables doesn't make it<br>
       this round, I will revive #119 to get that.<br>
<br>
OverloadedStrings: no<br>
  -- ^ yes, has many fans. But I believe that many might actuall<br>
       use that although what they really want is a monomorphic<br>
<br>
         "foo" :: Text<br>
<br>
       and I wonder if there is a way to give them that.<br>
<br>
       Also, some report that too much polymorphism can hurt, e.g. in<br>
<br>
         is_vowel c = c `elem` "aeiou"<br>
<br>
       Three is also 12% Aloofness and 12% Contentionsness, which are<br>
       not to be dismissed.<br>
<br>
       So I am inclined to leave this out, for this round at least.<br>
<br>
MultiWayIf: no<br>
  -- ^ in light of discussion around a multi-case, maybe premature<br>
<br>
<br>
The remaining ones,<br>
*Main> putStr $ unlines [ ext ++ ": yes" | E{..} <- M.elems exts, not<br>
(survey_no > 10 && survey_no * 2 > survey_yes), not (5 * survey_yes ><br>
survey_total)  ]<br>
<br>
Kinda clear:<br>
<br>
BinaryLiterals: yes<br>
DeriveLift: yes<br>
EmptyCase: yes<br>
EmptyDataDecls: yes<br>
EmptyDataDeriving: yes<br>
ExistentialQuantification: yes<br>
  -- ^ Or is anything wrong with that?<br>
ExplicitForAll: yes<br>
GADTSyntax: yes<br>
  -- ^ In case GADTs don’t make it<br>
InstanceSigs: yes<br>
NamedFieldPuns: yes<br>
NondecreasingIndentation: yes<br>
  -- ^ It’s Haskell98<br>
and the current default(!), but not Haskell2010?<br>
NumericUnderscores: yes<br>
RecordWildCards: yes<br>
UnliftedFFITypes: yes<br>
StarIsType: yes<br>
  -- ^ It’s the default now. Probably too early to turn off?<br>
<br>
DefaultSignatures: no<br>
  -- ^ Deriving via is probably preferrable these days<br>
DeriveAnyClass: no<br>
LinearTypes: no<br>
PatternSynonyms: no<br>
  -- ^ I like them, but maybe a bit too early<br>
MonadFailDesugaring: no<br>
  -- ^ This extension is temporary, and will be deprecated in a future<br>
release.<br>
QualifiedDo: no<br>
Safe: no<br>
<br>
No expert on these, will read your rationales:<br>
<br>
FunctionalDependencies: maybe<br>
StandaloneKindSignatures: maybe<br>
CUSKs: maybe<br>
GHCForeignImportPrim: maybe<br>
LexicalNegation: maybe<br>
  -- ^ Unsure about the maturity of the whitespace sensitiviy trend<br>
PolyKinds: maybe<br>
  -- ^ Does it even make sense to vote on this?<br>
<br>
<br>
Quite a long list! Surely the next years will be easier.<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>