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