<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Here is my re-updated vote (I had forgotten to move `ForeignFunctionInterface` to the Haskell2010 section. I assume Joachim is taking special precautions, but it's better for my peace of mind):</div><div><br></div><div><span class="gmail-im">## I don't know what these are<br><br>LexicalNegation: maybe<br>NondecreasingIndentation: maybe<br><br>## No opinion yet<br><br>Probably none of these are popular enough to be worth including in<br>this first round anyway.<br><br>BlockArguments: maybe<br>CUSKs: maybe<br>DataKinds: maybe<br></span>DefaultSignatures: maybe<br>DisambiguateRecordFields: maybe<br>DuplicateRecordFields: maybe<span class="gmail-im"><br>ImportQualifiedPost: maybe<br>MonadComprehensions: maybe<br>   ^ It's fairly popular this one, but I don't know the effects on<br>   type inference. I feel it may be a similar case as the OverloadedX<br>   extensions, in which case it feels premature to add it to GHC2021.<br>NamedFieldPuns: maybe<br>   ^ While I live and breath for NamedFieldPuns, it does remove some<br>   shadowing warnings, so it does make some things harder, and it's<br>   likely that we want this one left out of this round.<br>NamedWildCards: maybe<br>RecordWildCards: maybe<br>NullaryTypeClasses: maybe<br></span>NumDecimals: maybe<br>PackageImports: maybe<br>ParallelListComp: maybe<br>PolyKinds: maybe<span class="gmail-im"><br>RankNTypes: maybe<br>RecursiveDo: maybe<br>TransformListComp: maybe<br>TypeInType: maybe<br>TypeSynonymInstances: maybe<br>UnliftedFFITypes: maybe<br>ScopedTypeVariables: maybe<br>    ^ There seem to be discussion about the type-signature-in-pattern<br>    part of this extension, which I have no opinion about. I'm very<br>    much in favour of the bind-type-signature-variable parts. But I<br>    guess this is likely to be too controversial an extension for this<br>    round.<br>UnicodeSyntax: maybe<br>    ^ I think it changes error messages. I don't think that we can<br>    make error messages in Unicode by default. If it only affects<br>    parsing, then I'm in favour.<br><br>## Just adds syntax<br><br>These extensions simply add syntax, they bear little risk, I see no<br>reason not to avoid them. Let me include all of the deriving things in<br>this category.<br><br>Arrows: yes<br>BangPatterns: yes<br>BinaryLiterals: yes<br></span>DeriveDataTypeable: yes<br>DeriveFoldable: yes<br>DeriveFunctor: yes<span class="gmail-im"><br>DeriveGeneric: yes<br>DeriveLift: yes<br>DeriveTraversable: yes<br>DerivingStrategies: yes<br>GeneralisedNewtypeDeriving: yes<br>    ^ Though this technically collides with the DeriveX syntax, the<br>    collision is innocuous: you would derive the same functor whether<br>    you are using the stock strategy or the newtype strategy.<br>TypeFamilies: yes<br>TypeFamilyDependencies: yes<br>GADTs: yes<br>GADTSyntax: yes<br>    ^ Implied by GADTs<br>TypeOperators: yes<br>ConstraintKinds: yes<br>FunctionalDependencies: yes<br>EmptyCase: yes<br>HexFloatLiterals: yes<br>ConstrainedClassMethods: yes<br>ExplicitForAll: yes<br>ExplicitNamespaces: yes<br>KindSignatures: yes<br>NegativeLiterals: yes<br>NumericUnderscores: yes<br>PartialTypeSignatures: yes<br>ViewPatterns: yes<br>TypeApplications: yes<br>StandaloneDeriving: yes<br></span><span>PostfixOperators: yes</span></div><div>    ^ Not really new syntax, rather refined semantics in existing syntax. But just as</div><div>    innocuous.<br></div><div><br><span></span></div><div><div><div class="gmail-im"><span></span>MonoLocalBinds: yes<br>   ^ MonoLocalBinds is implied by both GADTs and TypeFamilies. And it<br>   makes my addition of GADTs and TypeFamilies in this section a<br>   lie. We may want to have NoMonoLocalBinds turned on forcefully (or<br>   GADTSyntax but not GADTs nor TypeFamilies this time around). But<br>   MonoLocalBinds really want to become the default. So I'm inclined<br>   to let it be.<br><br>### Exceptions to the rule<br><br>DeriveAnyClass: no<br>   ^ This doesn't so much add syntax as generalises syntax (as opposed<br>   to DeriveFunctor, for instance, which may be read as adding Functor<br>   to the syntactic list of things which can appear in the Derive<br>   list). This probably leads to too many ambiguities for the first<br>   round.<br>DerivingVia: no<br>   ^ It's pretty innocuous, but too recent for inclusion.<br>TupleSections: probably not<br>   ^ I believe there has been some discussion about conflicts between<br>   TupleSection and terminal commas. So while it's a fairly popular<br>   extension, I think it's safer to keep it out.<br>ExistentialQuantification: probably notation<br>   ^ I don't think we need this syntax if GADTs are around. So maybe<br>   I'd rather see that as not being a default, so as to nudge<br>   programmers to the GADT syntax.<br>LambdaCase: probably not<br>   ^ As popular and lovely as this extension is, considering that<br>   there are some discussion on its future, I'm sadly compelled to<br>   give it a pass.<br>   <br>## Type class stuff<br><br></div></div>MultiParamTypeClasses: yes<br>FlexibleContexts: yes<br>FlexibleInstances: yes<span class="gmail-im"><br>   ^ I believe both FlexibleContexts and FlexibleInstances to be<br>   almost always innocuous, so they should probably make it in.<br>UndecidableInstances: no<br>UndecidableSuperClasses: no<br>   ^ The UndecidableX are not as scary as they look, yet, I don't<br>   think they ought to be there by default. This termination check<br>   exists for a reason. It's true that, today, many (most?) instances<br>   using MultiParamTypeClasses need UndecidableInstances, though. But<br>   it could probably be improved.<br><br>## Feature switches<br><br>These are switches for advanced feature (or "slow" features in the<br>case of the case of Template Haskell), they should never be on by<br>default.<br><br>NoImplicitPrelude: no<br>TemplateHaskell: no<br>TemplateHaskellQuotes: no<br>QuasiQuotes: no<br>RebindableSyntax: no<br></span>CApiFFI: no<br>CPP: no<br>GHCForeignImportPrim: no<br>InterruptibleFFI: no<br>MagicHash: no<br>UnboxedSums: no<br>UnboxedTuples: no<span class="gmail-im"><br>    ^ Though, frankly, all of MagicHash, UnboxedSums, and<br>    UnboxedTuples could very well become not-advanced in a<br>    not-so-far-future. Then we could turn them on by default as<br>    just-adding-syntax.<br><br>### Forks on the roads<br><br>These are not so much advanced features as features that change<br>significantly the meaning of the module they are in.<br><br>Strict: no<br>StrictData: no<br><br>## Module metadata<br><br>None of these should be on.<br><br></span>Safe: no<br>Trustworthy: no<br>Unsafe: no<br><span class="gmail-im"><br>## OverloadedX<br><br>These extensions can confuse type inference, yielding ambiguous type<br>variables message. And as much as I like them, I don't think it's safe<br>to include them yet. Not until we have a reasonable story for<br>defaulting literals.<br><br>OverloadedLabels: no<br>OverloadedLists: no<br>OverloadedStrings: no<br><br>## Difficult errors<br><br>These extension yield type errors which are quite a bit more difficult<br>than turning them off. So they are better left out.<br><br>AllowAmbiguousTypes: no<br><br>## Not ready yet<br><br>Hodgepodge list.<br><br>ApplicativeDo: no<br>LinearTypes: no<br></span>ImpredicativeTypes: no<br>QualifiedDo: no<br>QuantifiedConstraints: no<span class="gmail-im"><br>RoleAnnotations: no<br>StaticPointers: no<br>StandaloneKindSignatures: no<br>UnliftedNewtypes: no<br><br>## Already in GHC<br><br>MonadFailDesugaring: yes<br>StarIsType: yes<br>    ^ We should not turn this one off until standalone kind signatures<br>    are also the default, in my opinion.<br><br>## Already in Haskell 2010<br><br>EmptyDataDecls: yes<br>EmptyDataDeriving: yes<br>ForeignFunctionInterface: yes<br><br>## Uncommon extensions<br><br>ExtendedDefaultRules: no<br>ImplicitParams: no<br>InstanceSigs: no<br>  -- ^ It does feel mostly innocuous on the surface, but it has a<br>  probably surprising semantics. Considering that it's quite rarely<br>  used, probably better left out.<br></span>LiberalTypeSynonyms: no<span class="gmail-im"><br>NoMonomorphismRestriction: no<br>NoPatternGuards: no<br>NoTraditionalRecordSyntax: no<br>PatternSynonyms: no<br><br>## Deprecated extensions<br><br>OverlappingInstances: no<br>DatatypeContexts: no<br></span>IncoherentInstances: no<br>MultiWayIf: no<br>NPlusKPatterns: no <br></div></div></div></div></div><br></div>