[ghc-steering-committee] #380 GHC2021: Current status

Sat Dec 5 01:04:13 UTC 2020

Here are my updated votes, I changed:

> StarIsType: yes (convinced by Joachim not to rock the boat too much at first)
> DerivingVia: no (convinced by Arnaud that it's not mature enough yet)

---

## syntax

BangPatterns: yes
BinaryLiterals: yes
EmptyCase: yes
EmptyDataDecls: yes
ExplicitForAll: yes
ExplicitNamespaces: yes
GADTSyntax: yes
HexFloatLiterals: yes
ImportQualifiedPost: yes
InstanceSigs: yes
KindSignatures: yes
MonadFailDesugaring: yes
NegativeLiterals: yes
NumericUnderscores: yes
PatternSynonyms: yes
PostfixOperators: yes
StarIsType: yes
TypeApplications: yes

OverloadedLists: yes
OverloadedStrings: yes
  I have to enable OverloadedStrings regularly,
  and it's one of the few extensions GHC
  cannot suggest, which trips up my editor, and by
  extension me, on a regular basis. I admit that I've
  never actually used OverloadedLists, but I like it
  as a direction for the language.

BlockArguments: maybe
  I like this one, but it feels a bit recent.
MonadComprehensions: maybe
NumDecimals: maybe
ParallelListComp: maybe
RecursiveDo: maybe

ApplicativeDo: no
Arrows: no
LexicalNegation: no
NPlusKPatterns: no
NondecreasingIndentation: no
OverloadedLabels: no
QualifiedDo: no
RebindableSyntax: no
  It's marked legacy syntax, let's be bold and get rid of it.
TransformListComp: no
TupleSections: no
  This conflicts with proposals around trailing commas
  that we may want to consider.
UnicodeSyntax: no
ViewPatterns: no

LambdaCase: no
MultiWayIf: no
  I like both of these, but I've been convinced to wait out
  the current discussion around alternate designs.

## types

ConstrainedClassMethods: yes
ConstraintKinds: yes
DataKinds: yes
DefaultSignatures: yes
ExistentialQuantification: yes
  This is occasionally useful, and purely opt-in.
FlexibleContexts: yes
FlexibleInstances: yes
FunctionalDependencies: yes
GADTs: yes
MonoLocalBinds: yes
  I think I actually prefer this even in the absence of GADTs.
MultiParamTypeClasses: yes
PolyKinds: yes
RankNTypes: yes
RoleAnnotations: yes
ScopedTypeVariables: yes
StandaloneKindSignatures: yes
TypeFamilies: yes
TypeFamilyDependencies: yes
TypeOperators: yes
TypeSynonymInstances: yes

NamedWildCards: yes
PartialTypeSignatures: yes
  These are useful for debugging and warned on by default.

UndecidableInstances: maybe
UndecidableSuperClasses: maybe
  Is it really that bad if we allow the possibility of the
  type checker looping? This does not introduce unsoundness.

CUSKs: no
DatatypeContexts: no
ImplicitParams: no
ImpredicativeTypes: no
IncoherentInstances: no
LiberalTypeSynonyms: no
LinearTypes: no
NullaryTypeClasses: no
OverlappingInstances: no
QuantifiedConstraints: no
TypeInType: no

## records

DisambiguateRecordFields: yes
  This only allows unambiguous uses of fields,
  so it seems very safe.

NamedFieldPuns: yes
RecordWildCards: yes
  I know these are controversial, but they're opt-in
  and super useful.

DuplicateRecordFields: maybe
  There are some valid critiques of this extension,
  but I think it's still generally useful, at least
  until RecordDotSyntax is implemented and stable.

## deriving

DeriveDataTypeable: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveLift: yes
DeriveTraversable: yes
GeneralisedNewtypeDeriving: yes
StandaloneDeriving: yes

DerivingStrategies: maybe

DeriveAnyClass: no
DerivingVia: no
EmptyDataDeriving: no

## low-level / ffi

CApiFFI: no
ForeignFunctionInterface: no
  I know this is part of Haskell2010, but I feel like
  FFI is niche and low-level enough to warrant a marker
GHCForeignImportPrim: no
InterruptibleFFI: no
MagicHash: no
UnboxedSums: no
UnboxedTuples: no
UnliftedFFITypes: no
UnliftedNewtypes: no

## other

AllowAmbiguousTypes: no
CPP: no
ExtendedDefaultRules: no
NoImplicitPrelude: no
NoMonomorphismRestriction: no
NoPatternGuards: no
NoTraditionalRecordSyntax: no
PackageImports: no
QuasiQuotes: no
Safe: no
StaticPointers: no
Strict: no
StrictData: no
TemplateHaskell: no
TemplateHaskellQuotes: no
Trustworthy: no
Unsafe: no

On Fri, Dec 4, 2020, at 13:44, Richard Eisenberg wrote:
> 
> 
> > On Dec 4, 2020, at 10:29 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > I think NoStarIsType, as sensible it may be to most of us, _will_ deepy
> > annoy some people. Let’s build credibility and acceptance with GHC2021,
> > and have lots of happy people out there. And (if anything!) use later
> > versions to do more contentious things.
> 
> I deeply dislike -XStarIsType. But I'm convinced here. My updated vote is below.
> 
> Richard
> 
> *Module System
> =============*
> 
> ImportQualifiedPost: yes
> PackageImports: obscure
> NoImplicitPrelude: breaking
> 
> *Notation
> ========*
> 
> BlockArguments: yes
> MultiWayIf: might change
> LambdaCase: might change
> BinaryLiterals: yes
> HexFloatLiterals: yes
> NumericUnderscores: yes
> NumDecimals: yes
> OverloadedStrings: bad for beginners
> OverloadedLists: bad for beginners
> OverloadedLabels: obscure
> EmptyCase: yes
> PostfixOperators: yes
> LexicalNegation: yes
> UnicodeSyntax: yes
> NegativeLiterals: superseded
> TupleSections: yes
> ImplicitParams: obscure
> ParallelListComp: yes
> RecursiveDo: obscure
> TransformListComp: obscure
> Arrows: obscure
> ApplicativeDo: breaking
> QualifiedDo: too fresh
> MonadComprehensions: bad for beginners
> NondecreasingIndentation: obscure
> RebindableSyntax: breaking
> ExplicitNamespaces: yes
> 
> *Data Types
> ==========
> *
> DatatypeContexts: no
> ExistentialQuantification: yes
> EmptyDataDecls: yes
> RoleAnnotations: yes
> StrictData: breaking
> GADTSyntax: yes
> GADTs: obscure
> 
> *Patterns and Guards
> ===================*
> 
> BangPatterns: yes
> ViewPatterns: yes
> PatternSynonyms: too fresh
> NoPatternGuards: breaking
> NPlusKPatterns: deprecated
> 
> *Records
> =======*
> 
> NamedFieldPuns: yes
> RecordWildCards: confusing
> DisambiguateRecordFields: yes
> DuplicateRecordFields: might change
> NoTraditionalRecordSyntax: no
> 
> *Deriving
> =======*
> 
> DeriveGeneric: yes
> DeriveLift: yes
> DeriveDataTypeable: yes
> EmptyDataDeriving: yes
> StandaloneDeriving: yes
> DeriveFunctor: yes
> DeriveFoldable: yes
> DeriveTraversable: yes
> DerivingStrategies: yes
> DerivingVia: yes
> GeneralisedNewtypeDeriving: yes
> DeriveAnyClass: dangerous
> 
> *Class System
> ============*
> 
> MultiParamTypeClasses: yes
> NullaryTypeClasses: superseded
> ConstraintKinds: yes
> TypeSynonymInstances: yes
> FlexibleInstances: yes
> FlexibleContexts: yes
> ConstrainedClassMethods: yes
> DefaultSignatures: yes
> InstanceSigs: yes
> ExtendedDefaultRules: might change
> FunctionalDependencies: obscure
> QuantifiedConstraints: too fresh
> UndecidableInstances: dangerous
> IncoherentInstances: dangerous
> UndecidableSuperClasses: dangerous
> OverlappingInstances: superseded
> *
> *
> Types
> *=====*
> 
> RankNTypes: yes
> StandaloneKindSignatures: yes
> KindSignatures: yes
> LiberalTypeSynonyms: confusing
> ScopedTypeVariables: might change
> ExplicitForAll: yes
> AllowAmbiguousTypes: dangerous
> ImpredicativeTypes: too fresh
> MonoLocalBinds: breaking
> NoMonomorphismRestriction: debate!
> PartialTypeSignatures: obscure
> NamedWildCards: yes
> LinearTypes: too fresh
> TypeApplications: yes
> PolyKinds: yes
> TypeOperators: yes
> StarIsType: yes
> TypeFamilies: obscure
> TypeFamilyDependencies: obscure
> DataKinds: might change
> 
> *FFI
> ===*
> 
> ForeignFunctionInterface: yes
> CApiFFI: obscure
> GHCForeignImportPrim: obscure
> InterruptibleFFI: obscure
> UnliftedFFITypes: obscure
> StaticPointers: obscure
> 
> *Low Level
> =========*
> 
> UnboxedSums: obscure
> UnboxedTuples: obscure
> MagicHash: obscure
> UnliftedNewtypes: yes
> 
> *Macros
> ======*
> 
> CPP: obscure
> TemplateHaskell: TH
> TemplateHaskellQuotes: yes
> QuasiQuotes: TH
> 
> 
> *Other
> =====*
> 
> Unsafe: no
> Safe: no
> Trustworthy: no
> Strict: no
> 
> *Obsolete/Deprecated
> ===================*
> 
> CUSKs: no
> TypeInType: no
> MonadFailDesugaring: maybe
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>