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

[Richard Eisenberg]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/ef04d5d6/attachment.html>