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

Spiwack, Arnaud arnaud.spiwack at tweag.io
Wed Dec 2 08:43:01 UTC 2020

Here is my updated vote:

## I don't know what these are

LexicalNegation: maybe
NondecreasingIndentation: maybe

## No opinion yet

Probably none of these are popular enough to be worth including in
this first round anyway.

BlockArguments: maybe
CUSKs: maybe
DataKinds: maybe
DefaultSignatures: maybe
DisambiguateRecordFields: maybe
DuplicateRecordFields: maybe
ImportQualifiedPost: maybe
MonadComprehensions: maybe
   ^ It's fairly popular this one, but I don't know the effects on
   type inference. I feel it may be a similar case as the OverloadedX
   extensions, in which case it feels premature to add it to GHC2021.
NamedFieldPuns: maybe
   ^ While I live and breath for NamedFieldPuns, it does remove some
   shadowing warnings, so it does make some things harder, and it's
   likely that we want this one left out of this round.
NamedWildCards: maybe
RecordWildCards: maybe
NullaryTypeClasses: maybe
NumDecimals: maybe
PackageImports: maybe
ParallelListComp: maybe
PolyKinds: maybe
RankNTypes: maybe
RecursiveDo: maybe
TransformListComp: maybe
TypeInType: maybe
TypeSynonymInstances: maybe
UnliftedFFITypes: maybe
ScopedTypeVariables: maybe
    ^ There seem to be discussion about the type-signature-in-pattern
    part of this extension, which I have no opinion about. I'm very
    much in favour of the bind-type-signature-variable parts. But I
    guess this is likely to be too controversial an extension for this
UnicodeSyntax: maybe
    ^ I think it changes error messages. I don't think that we can
    make error messages in Unicode by default. If it only affects
    parsing, then I'm in favour.

## Just adds syntax

These extensions simply add syntax, they bear little risk, I see no
reason not to avoid them. Let me include all of the deriving things in
this category.

Arrows: yes
BangPatterns: yes
BinaryLiterals: yes
DeriveDataTypeable: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveLift: yes
DeriveTraversable: yes
DerivingStrategies: yes
GeneralisedNewtypeDeriving: yes
    ^ Though this technically collides with the DeriveX syntax, the
    collision is innocuous: you would derive the same functor whether
    you are using the stock strategy or the newtype strategy.
TypeFamilies: yes
TypeFamilyDependencies: yes
GADTs: yes
GADTSyntax: yes
    ^ Implied by GADTs
TypeOperators: yes
ConstraintKinds: yes
FunctionalDependencies: yes
EmptyCase: yes
HexFloatLiterals: yes
ConstrainedClassMethods: yes
ExplicitForAll: yes
ExplicitNamespaces: yes
KindSignatures: yes
NegativeLiterals: yes
NumericUnderscores: yes
PartialTypeSignatures: yes
ViewPatterns: yes
TypeApplications: yes
StandaloneDeriving: yes
PostfixOperators: yes
    ^ Not really new syntax, rather refined semantics in existing syntax.
But just as

MonoLocalBinds: yes
   ^ MonoLocalBinds is implied by both GADTs and TypeFamilies. And it
   makes my addition of GADTs and TypeFamilies in this section a
   lie. We may want to have NoMonoLocalBinds turned on forcefully (or
   GADTSyntax but not GADTs nor TypeFamilies this time around). But
   MonoLocalBinds really want to become the default. So I'm inclined
   to let it be.

### Exceptions to the rule

DeriveAnyClass: no
   ^ This doesn't so much add syntax as generalises syntax (as opposed
   to DeriveFunctor, for instance, which may be read as adding Functor
   to the syntactic list of things which can appear in the Derive
   list). This probably leads to too many ambiguities for the first
DerivingVia: no
   ^ It's pretty innocuous, but too recent for inclusion.
TupleSections: probably not
   ^ I believe there has been some discussion about conflicts between
   TupleSection and terminal commas. So while it's a fairly popular
   extension, I think it's safer to keep it out.
ExistentialQuantification: probably notation
   ^ I don't think we need this syntax if GADTs are around. So maybe
   I'd rather see that as not being a default, so as to nudge
   programmers to the GADT syntax.
LambdaCase: probably not
   ^ As popular and lovely as this extension is, considering that
   there are some discussion on its future, I'm sadly compelled to
   give it a pass.

## Type class stuff

MultiParamTypeClasses: yes
FlexibleContexts: yes
FlexibleInstances: yes
   ^ I believe both FlexibleContexts and FlexibleInstances to be
   almost always innocuous, so they should probably make it in.
UndecidableInstances: no
UndecidableSuperClasses: no
   ^ The UndecidableX are not as scary as they look, yet, I don't
   think they ought to be there by default. This termination check
   exists for a reason. It's true that, today, many (most?) instances
   using MultiParamTypeClasses need UndecidableInstances, though. But
   it could probably be improved.

## Feature switches

These are switches for advanced feature (or "slow" features in the
case of the case of Template Haskell), they should never be on by

NoImplicitPrelude: no
TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no
RebindableSyntax: no
CApiFFI: no
CPP: no
ForeignFunctionInterface: no
GHCForeignImportPrim: no
InterruptibleFFI: no
MagicHash: no
UnboxedSums: no
UnboxedTuples: no
    ^ Though, frankly, all of MagicHash, UnboxedSums, and
    UnboxedTuples could very well become not-advanced in a
    not-so-far-future. Then we could turn them on by default as

### Forks on the roads

These are not so much advanced features as features that change
significantly the meaning of the module they are in.

Strict: no
StrictData: no

## Module metadata

None of these should be on.

Safe: no
Trustworthy: no
Unsafe: no

## OverloadedX

These extensions can confuse type inference, yielding ambiguous type
variables message. And as much as I like them, I don't think it's safe
to include them yet. Not until we have a reasonable story for
defaulting literals.

OverloadedLabels: no
OverloadedLists: no
OverloadedStrings: no

## Difficult errors

These extension yield type errors which are quite a bit more difficult
than turning them off. So they are better left out.

AllowAmbiguousTypes: no

## Not ready yet

Hodgepodge list.

ApplicativeDo: no
LinearTypes: no
ImpredicativeTypes: no
QualifiedDo: no
QuantifiedConstraints: no
RoleAnnotations: no
StaticPointers: no
StandaloneKindSignatures: no
UnliftedNewtypes: no

## Already in GHC

MonadFailDesugaring: yes
StarIsType: yes
    ^ We should not turn this one off until standalone kind signatures
    are also the default, in my opinion.

## Already in Haskell 2010

EmptyDataDecls: yes
EmptyDataDeriving: yes

## Uncommon extensions

ExtendedDefaultRules: no
ImplicitParams: no
InstanceSigs: no
  -- ^ It does feel mostly innocuous on the surface, but it has a
  probably surprising semantics. Considering that it's quite rarely
  used, probably better left out.
LiberalTypeSynonyms: no
NoMonomorphismRestriction: no
NoPatternGuards: no
NoTraditionalRecordSyntax: no
PatternSynonyms: no

## Deprecated extensions

OverlappingInstances: no
DatatypeContexts: no
IncoherentInstances: no
MultiWayIf: no
NPlusKPatterns: no

On Tue, Dec 1, 2020 at 6:31 PM Simon Marlow <marlowsd at gmail.com> wrote:

> I will also change DeriveAnyClass to no:
> ## Uncontroversial extensions
> I've been writing code with most of these enabled by default for quite
> some time now. It saves a lot of LANGUAGE pragmas. Other than
> RecordWildCards I doubt any of these are controversial.
> BangPatterns: yes
> BinaryLiterals: yes
> DataKinds: yes
> DeriveDataTypeable: yes
> DeriveGeneric: yes
> EmptyCase: yes
> ExistentialQuantification: yes
> FlexibleContexts: yes
> FlexibleInstances: yes
> GADTs: yes
> GeneralisedNewtypeDeriving: yes
> LambdaCase: yes
> MultiParamTypeClasses: yes
> MultiWayIf: yes
> NoMonomorphismRestriction: yes
> OverloadedStrings: yes
> PatternSynonyms: yes
> RankNTypes: yes
> RecordWildCards: yes
> ScopedTypeVariables: yes
> StandaloneDeriving: yes
> TupleSections: yes
> TypeFamilies: yes
> TypeSynonymInstances: yes
> NondecreasingIndentation: yes
> ConstrainedClassMethods: yes
> ConstraintKinds: yes
> DefaultSignatures: yes
> DeriveFoldable: yes
> DeriveFunctor: yes
> DeriveTraversable: yes
> EmptyDataDecls: yes
> EmptyDataDeriving: yes
> HexFloatLiterals: yes
> ImportQualifiedPost: yes
> InstanceSigs: yes
> KindSignatures: yes
> LiberalTypeSynonyms: yes
> NamedFieldPuns: yes
>   (I don't personally like this, but I can't justify having
>   RecordWildcards but not having this)
> NegativeLiterals: yes
> NumDecimals: yes
> PolyKinds: yes
> PostfixOperators: yes
> UnicodeSyntax: yes
>   (but only the language extension, not the UI changes)
> ## Extensions that are implied by others, or are irrelevant:
> GADTSyntax: yes
> ExplicitForAll: yes
> MonadFailDesugaring: irrelevant
> MonoLocalBinds: yes
> ## Extensions that are deprecated or exist for legacy reasons:
> DatatypeContexts: no
> NPlusKPatterns: no
> CUSKs: no
> NoPatternGuards: no
> ForeignFunctionInterface: yes
>   (already implied by Haskell2010, why do we have this but
>   NoPatternGuards?)
> NullaryTypeClasses: no
> OverlappingInstances: no
> IncoherentInstances: no
> TypeInType: no
> ## No to extensions that are too new to include in GHC2021:
> QualifiedDo: no
> LinearTypes: no
> BlockArguments: no
> LexicalNegation: no
> QuantifiedConstraints: no
> StandaloneKindSignatures: no
> StarIsType: no
> ## No to extensions that are opt-in by design:
> ApplicativeDo: no
>   (can lead to non-deterministic behaviour with non-rule-abiding
>   Applicative instances)
> PackageImports: no
> CPP: no
> DeriveLift: no
>   (only makes sense with TemplateHaskell, which is opt-in)
> TemplateHaskell: no
> TemplateHaskellQuotes: no
> QuasiQuotes: no
> RebindableSyntax: no
> Safe: no
> Strict: no
> StrictData: no
> Trustworthy: no
> Unsafe: no
> ExtendedDefaultRules: no
> NoImplicitPrelude: no
> ## No to unsafe extensions:
> UndecidableInstances: no
> UndecidableSuperClasses: no
> ## No to low-level extensions, not intended to be on by default:
> UnboxedTuples: no
> UnboxedSums: no
> MagicHash: no
> UnliftedFFITypes: no
> UnliftedNewtypes: no
> GHCForeignImportPrim: no
> InterruptibleFFI: no
> ## No to record-related extensions
> Records are in flux, let's not do any of this in GHC2021.
> DisambiguateRecordFields: no
> DuplicateRecordFields: no
> NoTraditionalRecordSyntax: no
> OverloadedLabels: no
> ## The rest
> That leaves some tricky ones, I'm putting all these as "no" or
> "maybe"; we could conservatively just say "no" to all of them.
> I'm voting NO on these:
> Arrows: no
>   (not widely used)
> ImplicitParams: no
>   (not widely used; questionable semantics; functionality available
>   with reflection package)
> ImpredicativeTypes: no
>   (I don't think we want this on by default, right?)
> ParallelListComp: no
>   (not widely used, most uses are covered by zip)
> StaticPointers: no
>   (quite a niche extension, only really useful with Distributed Haskell)
> TransformListComp: no
>   (not widely used)
> ViewPatterns: no
>   (not widely used, and in my opinion not a good design)
> DeriveAnyClass: no
>   (see discussion on the mailing list)
> I'm undecided on these:
> AllowAmbiguousTypes: maybe
> TypeApplications: maybe
> CApiFFI: maybe
>   (harmless, but a bit niche)
> DerivingVia: maybe
>   (not very widely-used, quite new)
> DerivingStrategies: maybe
>   (not very widely-used, quite new)
> FunctionalDependencies: maybe
>   (slightly inclined to "no", given the overlap
>   with TypeFamilies and the lack of widespread usage)
> ExplicitNamespaces: maybe
>   (might change, so defer?)
> MonadComprehensions: maybe
>   (does this make error messages worse?)
> PartialTypeSignatures: maybe
> NamedWildCards: maybe
> NumericUnderscores: maybe
> OverloadedLists: maybe
>   (impact on error messages?)
> RecursiveDo: maybe
>   (but introduced by a keyword so relatively harmless)
> RoleAnnotations: maybe
>   (not widely used, but when you need it you need it)
> TypeFamilyDependencies: maybe
>   (not widely used, but when you need it you need it)
> TypeOperators: maybe
> On Tue, 1 Dec 2020 at 08:51, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>> Hi,
>> Am Dienstag, den 01.12.2020, 00:43 -0800 schrieb Alejandro Serrano
>> Mena:
>> > Thanks everybody for an illuminating discussion about DeriveAnyClass.
>> > I was not aware of the dark corners of the extension (and actually,
>> > now I find it weird that GHC itself suggests that extension!). Here
>> > are my updated votes
>> Noted!
>> > apart from a ’No’ to DeriveAnyClass I’ve updated my votes of
>> > StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’.
>> JFTR, you also changed OverloadedLists and OverloadedStrings from maybe
>> to yes.
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/c3f078c0/attachment-0001.html>

More information about the ghc-steering-committee mailing list