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

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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee