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

[Simon Peyton Jones]

My votes.  I'm using Iavor's categorisation.

Many of these I don't feel strongly about.

Simon


Module System
=============

ImportQualifiedPost: yes
-- ^ This is relatively new, but it seems quite simple, and it does make
-- things read nicer.

-- | These are only needed under very special circumstances,
-- so it's good to be explicit:
PackageImports: no
NoImplicitPrelude: no


Notation
========

BlockArguments: no
-- ^ I prefer the extra parens

MultiWayIf: no
LambdaCase: no
-- ^ There is an on-going dicussion about \of,
-- whose outcome I don't want to pre-judge

-- | The various literal notations seem useful when you need them
-- and don't conflict with anything.
BinaryLiterals: yes
HexFloatLiterals: yes
NumericUnderscores: yes
NumDecimals: maybe

OverloadedStrings: yes
OverloadedLists: yes
-- | ^ These go together

OverloadedLabels: no
-- | ^ Still rather experimental

EmptyCase: yes
-- ^ Simple, useful, no conflicts

PostfixOperators: yes
LexicalNegation: maybe
UnicodeSyntax: maybe

NegativeLiterals: no
-- ^ It seems that `LexicalNegation` might be a nicer way to do this?

TupleSections: maybe
-- ^ I don't use this often, but I'd use it more often if it was on by default.

ImplicitParams: no
-- ^ I find these quite useful on occasion, but it does seem reasonable
-- to be explicit when you need them.

ParallelListComp: yes
-- ^ I find these to be a very nice generalization to list comprehensions
-- that makes some code way more readable than using `zip/zipWith`, just
-- like comprehensions are often nicer than `map` or `concatMap`

RecursiveDo: yes
-- ^ Seems useful when you need it, and it doesn't clash with anything,
-- so I see no reason to not have it on all the time.

TransformListComp: no
-- ^ In my mind these are just a bit too much syntactic sugar.

Arrows: no
-- ^ Big feature; if you want it, ask for it

ApplicativeDo: no
-- ^ Does not seem to have settled yet

QualifiedDo: no
-- ^ This is neat, but it is too new to be on by default.

MonadComprehensions: maybe
-- ^ I never really use these.
-- On occasion I've wanted `ApplicativeComprehensions` though.

NondecreasingIndentation: no
-- ^ This always felt like a hack to me.

RebindableSyntax: no
-- ^ Definitely not by default!

ExplicitNamespaces: maybe
-- ^ We need this if we also want pattern synonyms.


Data Types
==========

DatatypeContexts: no
-- ^ These are not really used much, and usually don't do what people expect.

ExistentialQuantification: yes
-- ^ This is quite useful, and has been around for a long time.

EmptyDataDecls: yes
-- ^ Seems more consistent to allow this

RoleAnnotations: yes
-- ^ Useful in the same way that type signatures are

StrictData: no
-- ^ Obviously not by default

GADTSyntax: yes
-- ^ I personally don't use this, but I know some folks like to write
-- their `data` declarations in this notation.

GADTs: no
-- ^ These can be useful, but it seems reasonable to enable them when
-- you need them, as they bring in quite a lot of machinery with them.


Patterns and Guards
===================
BangPatterns: yes
-- ^ Seem to be useful, and quite popular.

ViewPatterns: yes
-- ^ Useful on occasion, and I don't think calling out the extension
-- explicitly helps anyone.

PatternSynonyms: no
-- ^ These are quite useful, but I am not sure how stable is their design.

NoPatternGuards: no
-- ^ Conflicts with Haskell2010

NPlusKPatterns: no
-- ^ Conflicts with Haskell2010


Records
=======

-- | Useful abbreviation
NamedFieldPuns: yes

--| Makes it harder to determine binding site
RecordWildCards: no

-- | These seem to be largely about experimenting with new record
system, and I don't think any of them are quite ready to be on by default:
DisambiguateRecordFields: no
DuplicateRecordFields: no
NoTraditionalRecordSyntax: no


Deriving
=======

-- | Declaring these as extensions explicitly adds very little information.

EmptyDataDeriving: yes
-- ^ Useful for consistency

StandaloneDeriving: yes
-- ^ I find this quite useful on occasion, and does not conflict with anything


-- | Deriving particular classes
-- No harm in these
DeriveGeneric: yes
DeriveLift: yes
DeriveDataTypeable: yes
DeriveFunctor: yes
DeriveFoldable: yes
DeriveTraversable: yes

-- | Deriving methods
-- I'm less convinced that these are stable
DerivingStrategies: no
DerivingVia: no
GeneralisedNewtypeDeriving: no
DeriveAnyClass: no


Class System
============

MultiParamTypeClasses: yes
-- ^ Seems like a natural extension and does not really conflict with anything

NullaryTypeClasses: yes
-- ^ Seems like a natural extension and does not really conflict with anything

ConstraintKinds: yes
-- ^ These seem like a very nice fit with the rest of the kind system,

-- | These 3 seem to be quite common.  There are some reasons to be careful
-- when writing `FlexibleInstances`, but it seems that having the extension
-- does not really help much with those.
TypeSynonymInstances: yes
FlexibleInstances: yes
FlexibleContexts: yes

-- | A simple and useful generalisation
ConstrainedClassMethods: yes

-- | A bit more complicated
DefaultSignatures: no

-- | Simple and useful
InstanceSigs: yes

-- | This is mainly for GHCi; don't want this on by default!
ExtendedDefaultRules: no

FunctionalDependencies: no
-- ^ While I quite like the general idea here, I don't think we should
-- have these on by default.

QuantifiedConstraints: no
-- ^ These seem neat, but are quite new to be on by default.

UndecidableInstances: no
-- ^ These are a very special case, and ideally should be specified
-- on a per instance basis.

IncoherentInstances: no
-- ^ Why do we even have this? :)

UndecidableSuperClasses: no
-- ^ These are a very special case.

OverlappingInstances: no
-- ^ This has been subsumed by per-instance pragmas

Types
=====

RankNTypes: yes
-- ^ These are useful and have been around for a long time.  The design
-- seems to work well.

-- | These two seem useful, but I am not sure if they should be on by default.
-- If so, though, it makes sense to have both of them on.
StandaloneKindSignatures: yes
KindSignatures: yes

LiberalTypeSynonyms: maybe
-- ^ These seem useful, but can lead to some rather confusing situations
-- where types that look "normal" don't behave as you'd expect
-- (e..g, writing `[T]` fails because `T` happens to have `forall` in it)

-- | These two go together and seem quite useful, especially when writing
-- local type signatures.
ScopedTypeVariables: yes
ExplicitForAll: yes

AllowAmbiguousTypes: no
-- ^ Often these are unintentional, and are due to a mistake in the program.

ImpredicativeTypes: no
-- ^ Fairly new

MonoLocalBinds: yes
-- ^ Switched on by TypeFamilies; let's have it all the time
-- But debatable

NoMonomorphismRestriction: yes
-- ^ The monomrphism restriction seems to cause a lot of confusion, and I
-- am not sure that it's helped that much with efficiency

-- | Doesn't really seem to be commonly used.
PartialTypeSignatures: no
NamedWildCards: no

LinearTypes: no
-- ^ Too new to be standardized

TypeApplications: yes
-- ^ Super useful!

-- | These are all related to type-level programming, and while I don't think
-- they should be on by default, it might be useful to have a single flag that
-- turns a bunch of them on.
PolyKinds: yes
TypeOperators: yes
StarIsType: yes

-- More complicated
TypeFamilies: no
TypeFamilyDependencies: no
DataKinds: no

FFI
===
I don't think the FFI should be on by default, as it is used relatively
infrequently, although it might be nice if `ForeignFunctionInterface`
implied `CApiFFI`

ForeignFunctionInterface: no
CApiFFI: no
GHCForeignImportPrim: no
InterruptibleFFI: no
UnliftedFFITypes: no
StaticPointers: no


Low Level
=========

These are for low-level hacking, so I don't think they should be
on by default.  However, I wouldn't mind having a flag that enabled
all of them with a single extension (e.g., `UnliftedTypes`)

UnboxedSums: no
UnboxedTuples: no
MagicHash: no
UnliftedNewtypes: no

Macros
======

CPP: no
This is quite specialized, so it seems reasonable to be explicit about it.


I don't think these should be on by default, but I wouldn't mind it
if `TemplateHaskell` implied `QuasiQuotes`, so that when I use TH
I just need to turn on a single extension.:

TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no


Other
=====

-- | These are part of Safe Haskell and are there to be written explicitly
Unsafe: no
Safe: no
Trustworthy: no


Strict: no
-- ^ This is not Haskell! :-)

Obsolete/Deprecated
===================
CUSKs: no
TypeInType: no
MonadFailDesugaring: maybe