Just for the record, I voted "yes" on view patterns... :) On Sun, Dec 6, 2020 at 2:32 PM Joachim Breitner wrote:

Hi,

as the week ends, a quick update summarizing various inline “I’m convinced” vote updates from me:

PolyKinds: yes -- ^ Got convinced by Richard

CUSKs: no StandaloneKindSignatures: yes -- ^ A change from Haskell2010, but in a corner where the target audience probably prefers progress

MonomorphismRestriction: yes -- ^ Is in Haskell2010, I have no reason to change that

Controversial and/or pleaded against:

ViewPatterns: no (convinced by Iavor) GADTs: no (too controversial) ExistentialQuantification: no (convinced by Richard)

I continue to advocate for UnicodeSyntax, with the implied provision that -XGHC2021 will make GHC _accept_ Unicode syntax, but without writing error messages using it (i.e. no implied -fprint-unicode- syntax). I hope that at least those who have this on maybe (Arnaud, Iavor and SPJ) might be swayed by that clarification.

Unchanged votes follow:

PostfixOperators: yes

NamedWildCards: yes -- ^ Following Alejandro here: Seems safe and maybe more useful if it can be used without friction.

ForeignFunctionInterface: yes -- ^ As Simon M points out, this is part of Haskell2010, and was put on the ballet in this form (rather than NoForeignFunctionInterface) by accident. I do not want to remove anything that’s there (and I assume that nobody does without making that very explicit).

MonoLocalBinds: yes -- ^ Not an expert, but it’s probably nice if turning on GADTs or TypeFamilies (if they don't make it on their own) don’t change seemingly unrelated part of the code.

ImportQualifiedPost: yes -- ^ Personally don’t care a lot about it, but I don’t want to veto it either, so following Iavor here.

HexFloatLiterals: yes -- ^ More syntax for literals doesn’t hurt

Unchanged votes follow:

Let’s first get all those out of the way that are too contentions according to the data (with 2*no>yes votes):

My starting point here was: *Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, survey_no

...

10, survey_no * 2 > survey_yes ]

And that gave me the following:

AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BlockArguments: no CApiFFI: no CPP: no ConstrainedClassMethods: no DatatypeContexts: no DisambiguateRecordFields: no DuplicateRecordFields: no ExplicitNamespaces: no ExtendedDefaultRules: no ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InterruptibleFFI: no LiberalTypeSynonyms: no MagicHash: no MonadComprehensions: no NPlusKPatterns: no NoImplicitPrelude: no NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: no NumDecimals: no -- ^ Unsure about this one OverlappingInstances: no OverloadedLabels: no OverloadedLists: no PackageImports: no ParallelListComp: no PartialTypeSignatures: no -- ^ Unsure about this one, but trusting the crowd until convinced

otherwise QuantifiedConstraints: no QuasiQuotes: no RebindableSyntax: no RecursiveDo: no -- ^ I like that one. But probably not widespread enough. StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no TransformListComp: no Trustworthy: no TypeFamilyDependencies: no TypeInType: no TypeSynonymInstances: no UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no

Actually, some of them I disagree with, and believe they are safe to turn on by default, and would be happy to, with sufficient committee support:

NegativeLiterals: yes RoleAnnotations: yes UnicodeSyntax: yes -- ^ I ❤ unicode UnliftedNewtypes: yes -- ^ or is there something wrong with that?

Now to those with at least 20% popularity:

*Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), 5 * survey_yes > survey_total ]

These I happily go with, until I learn otherwise:

BangPatterns: yes ConstraintKinds: yes DataKinds: yes DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveTraversable: yes DerivingStrategies: yes DerivingVia: yes FlexibleContexts: yes FlexibleInstances: yes GeneralisedNewtypeDeriving: yes KindSignatures: yes LambdaCase: yes MultiParamTypeClasses: yes RankNTypes: yes StandaloneDeriving: yes TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeOperators: yes

There are some where I disagree with the crowd:

ScopedTypeVariables: no -- ^ Too much of a kitchen sink, some edges are rough, and some of its semantics (“bind type signatures unless in scope”) are being questioned.

If we had the plain PatternSignatures as a separate extension, I’d vote that in though. If ScopedTypeVariables doesn't make it this round, I will revive #119 to get that.

OverloadedStrings: no -- ^ yes, has many fans. But I believe that many might actuall use that although what they really want is a monomorphic

"foo" :: Text

and I wonder if there is a way to give them that.

Also, some report that too much polymorphism can hurt, e.g. in

is_vowel c = c `elem` "aeiou"

Three is also 12% Aloofness and 12% Contentionsness, which are not to be dismissed.

So I am inclined to leave this out, for this round at least.

MultiWayIf: no -- ^ in light of discussion around a multi-case, maybe premature

The remaining ones, *Main> putStr $ unlines [ ext ++ ": yes" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), not (5 * survey_yes > survey_total) ]

Kinda clear:

BinaryLiterals: yes DeriveLift: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExplicitForAll: yes GADTSyntax: yes -- ^ In case GADTs don’t make it InstanceSigs: yes NamedFieldPuns: yes NondecreasingIndentation: yes -- ^ It’s Haskell98 and the current default(!), but not Haskell2010? NumericUnderscores: yes RecordWildCards: yes UnliftedFFITypes: yes StarIsType: yes -- ^ It’s the default now. Probably too early to turn off!

DefaultSignatures: no -- ^ Deriving via is probably preferrable these days DeriveAnyClass: no LinearTypes: no PatternSynonyms: no -- ^ I like them, but maybe a bit too early MonadFailDesugaring: no -- ^ This extension is temporary, and will be deprecated in a future release. QualifiedDo: no Safe: no

No expert on these, will read your rationales:

FunctionalDependencies: maybe GHCForeignImportPrim: maybe LexicalNegation: maybe -- ^ Unsure about the maturity of the whitespace sensitiviy trend

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Did I make a plea in favour of view patterns? I thought I'd argued for the *alternative* view patterns, like Simon M. S | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 07 December 2020 10:00 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: Vote update | | Hi, | | | Am Sonntag, den 06.12.2020, 20:57 -0800 schrieb Iavor Diatchki: | > Just for the record, I voted "yes" on view patterns... :) | | ups, yes, it was SPJ’s plea that swayed me like a feather in the wind. | | Cheers, | Joachim | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C6c6504d2ad7743e | 9cc1908d89a96f377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374293 | 20415242213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zwUBdR2NKxtsr7qxL3hC | uYKwHI8StkX9FNDnvzOopDg%3D&reserved=0

I can't seem to find the e-mail, what are the alternative view patterns? On Mon, Dec 7, 2020 at 2:31 AM Joachim Breitner wrote:

Hi,

...

Did I make a plea in favour of view patterns? I thought I'd argued for

Am Montag, den 07.12.2020, 10:07 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: the *alternative* view patterns, like Simon M.

you pleat against it, so I changed my vote from yes to no.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Ah, yes, these are nice, I invented them too once :) I remember it being tricky to come up with a syntax that's not ambiguous, but I am sure we can do it, which convinces me to update my vote to a no also. On Mon, Dec 7, 2020 at 8:42 AM Joachim Breitner wrote:

Am Montag, den 07.12.2020, 08:36 -0800 schrieb Iavor Diatchki:

...

I can't seem to find the e-mail, what are the alternative view patterns?

https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternative

Cheers, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Wed, Nov 25, 2020 at 12:43 PM Joachim Breitner wrote:

Hi,

Thanks! I’ll update the tally later today.

Am Mittwoch, den 25.11.2020, 12:20 +0100 schrieb Spiwack, Arnaud:

...

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.

That is my sentiment as well, and I would phrase my vote as:

GHC2021 implies UnicodeSyntax, but not -fprint-unicode-syntax. Enabling UnicodeSyntax explicitly may still imply -fprint-unicode-syntax.

I guess the details of how GHC formats its messages are not strictly our authority, so I didn't spell this out, but yes: it helps to paint the picture here more clearly.

...

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.

Interesting, I don’t see a mention of this on

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... Can you elaborate?

The type signature in the instance declaration must be more polymorphic

I'm referring to: than (or the same as) the one in the class declaration, instantiated with the instance type. I may be overly conservative here, to be honest. But I'm just a tad hesitant. I should probably have written “a tad hesistant” instead of “no”, though. But this is a long list of extensions, and I was getting tired :) . Also thanks for looking up which extensions are already in GHC,

Haskell2010 and are deprecated. I should indicate that in the table somehow (or simply drop them from the ballot, at least the deprecated ones).

I don't claim exhaustiveness there. Nor am I 100% sure about correctness. For instance, I'm pretty sure that n+k patterns are considered deprecated, but the documentation doesn't reflect it. I still stored it in the deprecated section as there is basically no way that we turn this one on by default again.

El dom, 29 nov 2020 a las 12:12, Simon Marlow () escribió:

On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud wrote:

...

## 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

For what it's worth, I've been writing code with OverloadedStrings for several years now and in my experience it rarely causes a problem, even for beginners. The context almost always provides enough information to resolve the ambiguity. (admittedly I'm slightly surprised by this too, but experience has convinced me)

I don't have much experience with OverloadedLists, but I'd be prepared to believe that it's a similar story there too.

Adding to this, I think that both OverloadedStrings and OverloadedLists go very well with the idea of overloaded literals story that Haskell already has for numbers. Regards, Alejandro

OverloadedLabels is really a new syntactic form and doesn't fall into the same category as the other two here.

Cheers Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud wrote:

PostfixOperators: maybe

I'd like to make a case for this extension, on the grounds that it's a complete no-brainer. The name "PostfixOperators" makes it sound a lot more scary than it actually is. In fact it's just a tiny generalisation to the definition of left sections. You could almost regard it as a typo in the Haskell report - if it had been noticed that this rule was unnecessarily restrictive, I'm fairly sure it would have been fixed at the time. https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.... Cheers Simon

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; apart from a ’No’ to DeriveAnyClass I’ve updated my votes of StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’. -- the ones with comments CUSKs: no -- ^ according to the guide, this is superseded by StandaloneKindSignatures ConstrainedClassMethods: yes -- ^ it is implied by MultiParamTypeClasses anyway DefaultSignatures: no -- ^ as Joachim says, this should be succeeded by DerivingVia -- ^ anyway, this is one required for the writer of the class, so no big deal DeriveAnyClass: no -- ^ I think this makes no harm, and I tend to use deriving (ToJSON, FromJSON) DerivingVia: yes -- ^ even though it’s quite recent, I think it’s quite sensible and I don’t foresee many changes to it DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: maybe -- ^ this is a hard one! Not so terrible since it’s only required by the creator of the class, not of the instances MonadFailDesugaring: yes -- ^ isn’t this the default nowadays? MonoLocalBinds: maybe -- ^ this is implied by GADTs, but otherwise we shouldn’t MultiWayIf: no -- ^ still in discussion NamedWildCards: yes -- ^ not many people use this, but I think this is the sane default OverloadedLists: yes OverloadedStrings: yes -- ^ I would love to see these included, but I agree with the sentiment that they need more work PartialTypeSignatures: no -- ^ I really think that partial type signatures should not be accepted by default QuantifiedConstraints: maybe -- ^ too early, may want to refine this ScopedTypeVariables: yes -- ^ I think this is really well understood and people want it PatternSynonyms: maybe -- ^ we are still working out the edges of this -- these seem simple syntactic extensions -- many of them bring compatibility with the syntax of Java-like languages BinaryLiterals: yes HexFloatLiterals: yes NegativeLiterals: yes NumDecimals: yes NumericUnderscores: yes -- too early but wouldn’t care to introduce it StandaloneKindSignatures: yes ImportQualifiedPost: yes -- don’t know ForeignFunctionInterface: maybe GHCForeignImportPrim: maybe InterruptibleFFI: maybe LexicalNegation: maybe NondecreasingIndentation: maybe PackageImports: maybe ParallelListComp: maybe StarIsType: maybe TransformListComp: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe UnicodeSyntax: maybe -- the rest AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BangPatterns: yes BlockArguments: no CApiFFI: no CPP: no ConstraintKinds: yes DataKinds: yes DatatypeContexts: no DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes ExplicitForAll: yes ExplicitNamespaces: no ExtendedDefaultRules: no FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes -- ^ implied by GADTs anyway GADTs: yes GeneralisedNewtypeDeriving: yes ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InstanceSigs: yes KindSignatures: yes LambdaCase: yes LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MultiParamTypeClasses: yes NPlusKPatterns: no NamedFieldPuns: yes NoImplicitPrelude: no NoMonomorphismRestriction: yes NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: yes OverlappingInstances: no OverloadedLabels: no PolyKinds: yes PostfixOperators: yes QualifiedDo: no QuasiQuotes: no RankNTypes: no RebindableSyntax: no RecordWildCards: yes RecursiveDo: no RoleAnnotations: no Safe: no StandaloneDeriving: yes StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeFamilyDependencies: no TypeInType: maybe TypeOperators: yes TypeSynonymInstances: yes UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no ViewPatterns: yes On 30 Nov 2020 at 18:33:55, Richard Eisenberg wrote:

I also adopted Iavor's very helpful categorization.

I have not given any motivations below, as it's too difficult to read everyone's motivations inline. Instead, I give several varieties of "no" votes. Let's debate when someone disagrees with me. (To be clear: "obscure" just means that someone should manually opt in, not that the feature is really obscure.)

*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: deprecated TypeFamilies: obscure TypeFamilyDependencies: obscure DataKinds: might change

*FFI===*

ForeignFunctionInterface: obscure 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

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 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hopefully not too late to the party, but here are my votes. Like Richard’s, anything other than “yes” or “no” is the reason why it’s a “no”. Module System ============= ImportQualifiedPost: yes PackageImports: yes NoImplicitPrelude: a very breaking change Notation ======== BlockArguments: yes MultiWayIf: yes LambdaCase: yes BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: yes OverloadedStrings: more problems along the lines of `show 1` that seem to trip up a lot of newcomers. OverloadedLists: same as OverloadedStrings OverloadedLabels: not a no as much as a "no strong opinion" - personally never preferred it over alternatives. EmptyCase: yes PostfixOperators: yes LexicalNegation: yes UnicodeSyntax: yes NegativeLiterals: yes / N/A TupleSections: yes ImplicitParams: not obvious syntax, turning it on in cabal files/pragmas gives unfamiliar readers something to search for ParallelListComp: yes RecursiveDo: no strong opinion, I’ve never needed/used it in practice TransformListComp: adds more complexity to list comp notation, which is already complexity on do-notation Arrows: no strong opinion, but I’d lean towards no for the same reason as ImplicitParams ApplicativeDo: probably quite a breaking change in practice QualifiedDo: no MonadComprehensions: no NondecreasingIndentation: I had no idea about this until I saw the user guide example - this is probably unintuitive RebindableSyntax: definitely a breaking change, not least because it implies NoImplicitPrelude ExplicitNamespaces: yes Data Types ========== DatatypeContexts: no ExistentialQuantification: yes EmptyDataDecls: yes RoleAnnotations: yes StrictData: no, definitely a breaking change GADTSyntax: yes GADTs: the implied MonoLocalBinds probably means this would be a breaking change Patterns and Guards =================== BangPatterns: yes ViewPatterns: yes PatternSynonyms: no NoPatternGuards: no NPlusKPatterns: no Records ======= NamedFieldPuns: yes RecordWildCards: yes, but a weak yes DisambiguateRecordFields: yes DuplicateRecordFields: yes 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: no, I can imagine this would be rather dangerous Class System ============ MultiParamTypeClasses: yes NullaryTypeClasses: yes (albeit implied) ConstraintKinds: yes TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes ConstrainedClassMethods: yes DefaultSignatures: yes InstanceSigs: yes ExtendedDefaultRules: leads to some unexpected error messages FunctionalDependencies: yes QuantifiedConstraints: probably too new UndecidableInstances: noooo IncoherentInstances: noooo UndecidableSuperClasses: noooo OverlappingInstances: noooo Types ===== RankNTypes: yes StandaloneKindSignatures: yes KindSignatures: yes LiberalTypeSynonyms: yes ScopedTypeVariables: yes ExplicitForAll: yes AllowAmbiguousTypes: the class-site error is more useful than the use-site ImpredicativeTypes: not yet MonoLocalBinds: definitely a breaking change NoMonomorphismRestriction: I’d lean weakly towards “yes”, but happy to be overruled. PartialTypeSignatures: no NamedWildCards: yes LinearTypes: no TypeApplications: yes PolyKinds: yes TypeOperators: yes StarIsType: no, or even No TypeFamilies: yes TypeFamilyDependencies: yes DataKinds: yes FFI === ForeignFunctionInterface: no CApiFFI: no GHCForeignImportPrim: no InterruptibleFFI: no UnliftedFFITypes: no StaticPointers: no Low Level ========= UnboxedSums: yes UnboxedTuples: yes MagicHash: yes UnliftedNewtypes: yes Macros ====== CPP: no TemplateHaskell: yes TemplateHaskellQuotes: yes QuasiQuotes: yes Other ===== Unsafe: no Safe: no Trustworthy: no Strict: no Obsolete/Deprecated =================== CUSKs: no TypeInType: no MonadFailDesugaring: no If anything here seems contradictory, I can try to justify my answer. My general rule was, “if it’s a battle-tested extension to the language rather than a change, and it’s reasonably google-able/popular, it’s probably fine”. Thanks, Tom

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): ## 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 round. 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 innocuous. 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 round. 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 default. NoImplicitPrelude: no TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no RebindableSyntax: no CApiFFI: no CPP: 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 just-adding-syntax. ### 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 ForeignFunctionInterface: 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

Orthogonally, we probably want to wait a release or two before rolling a new extension into the default. So maybe it's a bit early for UnliftedNewtypes. On Thu, Dec 3, 2020 at 11:48 AM Simon Marlow wrote:

On Thu, 3 Dec 2020 at 08:51, Joachim Breitner wrote:

...

UnliftedNewtypes: yes -- ^ or is there something wrong with that?

I took the view that everything related to unboxed and unlifted types is "GHC-specific extension" territory, and unlikely to ever be in a Haskell language standard, so we probably shouldn't have these extensions on by default. That might be a somewhat outdated viewpoint these days, but still it's at least something we can apply consistently. So from my vote I lumped all these together:

...

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

Cheers Simon

...

Now to those with at least 20% popularity:

*Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), 5 * survey_yes > survey_total ]

These I happily go with, until I learn otherwise:

BangPatterns: yes ConstraintKinds: yes DataKinds: yes DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveTraversable: yes DerivingStrategies: yes DerivingVia: yes FlexibleContexts: yes FlexibleInstances: yes GADTs: yes GeneralisedNewtypeDeriving: yes KindSignatures: yes LambdaCase: yes MultiParamTypeClasses: yes RankNTypes: yes StandaloneDeriving: yes TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeOperators: yes ViewPatterns: yes

There are some where I disagree with the crowd:

ScopedTypeVariables: no -- ^ Too much of a kitchen sink, some edges are rough, and some of its semantics (“bind type signatures unless in scope”) are being questioned.

If we had the plain PatternSignatures as a separate extension, I’d vote that in though. If ScopedTypeVariables doesn't make it this round, I will revive #119 to get that.

OverloadedStrings: no -- ^ yes, has many fans. But I believe that many might actuall use that although what they really want is a monomorphic

"foo" :: Text

and I wonder if there is a way to give them that.

Also, some report that too much polymorphism can hurt, e.g. in

is_vowel c = c `elem` "aeiou"

Three is also 12% Aloofness and 12% Contentionsness, which are not to be dismissed.

So I am inclined to leave this out, for this round at least.

MultiWayIf: no -- ^ in light of discussion around a multi-case, maybe premature

The remaining ones, *Main> putStr $ unlines [ ext ++ ": yes" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), not (5 * survey_yes > survey_total) ]

Kinda clear:

BinaryLiterals: yes DeriveLift: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes -- ^ Or is anything wrong with that? ExplicitForAll: yes GADTSyntax: yes -- ^ In case GADTs don’t make it InstanceSigs: yes NamedFieldPuns: yes NondecreasingIndentation: yes -- ^ It’s Haskell98 and the current default(!), but not Haskell2010? NumericUnderscores: yes RecordWildCards: yes UnliftedFFITypes: yes StarIsType: yes -- ^ It’s the default now. Probably too early to turn off?

DefaultSignatures: no -- ^ Deriving via is probably preferrable these days DeriveAnyClass: no LinearTypes: no PatternSynonyms: no -- ^ I like them, but maybe a bit too early MonadFailDesugaring: no -- ^ This extension is temporary, and will be deprecated in a future release. QualifiedDo: no Safe: no

No expert on these, will read your rationales:

FunctionalDependencies: maybe StandaloneKindSignatures: maybe CUSKs: maybe GHCForeignImportPrim: maybe LexicalNegation: maybe -- ^ Unsure about the maturity of the whitespace sensitiviy trend PolyKinds: maybe -- ^ Does it even make sense to vote on this?

Quite a long list! Surely the next years will be easier.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Here are my votes, sorry to be so slow! ## syntax BangPatterns: yes BinaryLiterals: yes EmptyCase: yes EmptyDataDecls: yes ExplicitForAll: yes ExplicitNamespaces: yes GADTSyntax: yes HexFloatLiterals: yes ImportQualifiedPost: yes InstanceSigs: yes KindSignatures: yes MonadFailDesugaring: yes NegativeLiterals: yes NumericUnderscores: yes PatternSynonyms: yes PostfixOperators: yes TypeApplications: yes OverloadedLists: yes OverloadedStrings: yes I have to enable OverloadedStrings regularly, and it's one of the few extensions GHC cannot suggest, which trips up my editor, and by extension me, on a regular basis. I admit that I've never actually used OverloadedLists, but I like it as a direction for the language. BlockArguments: maybe I like this one, but it feels a bit recent. MonadComprehensions: maybe NumDecimals: maybe ParallelListComp: maybe RecursiveDo: maybe ApplicativeDo: no Arrows: no LexicalNegation: no NPlusKPatterns: no NondecreasingIndentation: no OverloadedLabels: no QualifiedDo: no RebindableSyntax: no StarIsType: no It's marked legacy syntax, let's be bold and get rid of it. TransformListComp: no TupleSections: no This conflicts with proposals around trailing commas that we may want to consider. UnicodeSyntax: no ViewPatterns: no LambdaCase: no MultiWayIf: no I like both of these, but I've been convinced to wait out the current discussion around alternate designs. ## types ConstrainedClassMethods: yes ConstraintKinds: yes DataKinds: yes DefaultSignatures: yes ExistentialQuantification: yes This is occasionally useful, and purely opt-in. FlexibleContexts: yes FlexibleInstances: yes FunctionalDependencies: yes GADTs: yes MonoLocalBinds: yes I think I actually prefer this even in the absence of GADTs. MultiParamTypeClasses: yes PolyKinds: yes RankNTypes: yes RoleAnnotations: yes ScopedTypeVariables: yes StandaloneKindSignatures: yes TypeFamilies: yes TypeFamilyDependencies: yes TypeOperators: yes TypeSynonymInstances: yes NamedWildCards: yes PartialTypeSignatures: yes These are useful for debugging and warned on by default. UndecidableInstances: maybe UndecidableSuperClasses: maybe Is it really that bad if we allow the possibility of the type checker looping? This does not introduce unsoundness. CUSKs: no DatatypeContexts: no ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no LiberalTypeSynonyms: no LinearTypes: no NullaryTypeClasses: no OverlappingInstances: no QuantifiedConstraints: no TypeInType: no ## records DisambiguateRecordFields: yes This only allows unambiguous uses of fields, so it seems very safe. NamedFieldPuns: yes RecordWildCards: yes I know these are controversial, but they're opt-in and super useful. DuplicateRecordFields: maybe There are some valid critiques of this extension, but I think it's still generally useful, at least until RecordDotSyntax is implemented and stable. ## deriving DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingVia: yes GeneralisedNewtypeDeriving: yes StandaloneDeriving: yes DerivingStrategies: maybe DeriveAnyClass: no EmptyDataDeriving: no ## low-level / ffi CApiFFI: no ForeignFunctionInterface: no I know this is part of Haskell2010, but I feel like FFI is niche and low-level enough to warrant a marker GHCForeignImportPrim: no InterruptibleFFI: no MagicHash: no UnboxedSums: no UnboxedTuples: no UnliftedFFITypes: no UnliftedNewtypes: no ## other AllowAmbiguousTypes: no CPP: no ExtendedDefaultRules: no NoImplicitPrelude: no NoMonomorphismRestriction: no NoPatternGuards: no NoTraditionalRecordSyntax: no PackageImports: no QuasiQuotes: no Safe: no StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no Unsafe: no On Thu, Dec 3, 2020, at 11:15, Alejandro Serrano Mena wrote:

Here are my new votes, after several discussions, and reading a bit about defaults (like for StarIsType) in the User Guide.

-- the ones with comments CUSKs: no -- ^ according to the guide, this is superseded by StandaloneKindSignatures ConstrainedClassMethods: yes -- ^ it is implied by MultiParamTypeClasses anyway DefaultSignatures: no -- ^ as Joachim says, this should be succeeded by DerivingVia -- ^ anyway, this is one required for the writer of the class, so no big deal DeriveAnyClass: no -- ^ given our discussion DerivingVia: yes -- ^ even though it’s quite recent, I think it’s quite sensible and I don’t foresee many changes to it DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: maybe -- ^ this is a hard one! Not so terrible since it’s only required by the creator of the class, not of the instances MonadFailDesugaring: yes -- ^ isn’t this the default nowadays? MonoLocalBinds: yes -- ^ this is implied by GADTs and TypeFamilies MultiWayIf: no -- ^ still in discussion NamedWildCards: yes -- ^ not many people use this, but I think this is the sane default OverloadedLists: yes OverloadedStrings: yes -- ^ I would love to see these included, but I agree with the sentiment that they need more work PartialTypeSignatures: no -- ^ I really think that partial type signatures should not be accepted by default QuantifiedConstraints: no -- ^ too early ScopedTypeVariables: yes -- ^ I think this is really well understood and people want it PatternSynonyms: maybe -- ^ we are still working out the edges of this ForeignFunctionInterface: yes RankNTypes: yes UnicodeSyntax: yes -- ^ following Joachim’s suggestion: enable this for syntax but *not* for error messages TypeInType: maybe -- ^ this simply implies PolyKinds, DataKinds, KindSignatures, according to the documentation StarIsType: yes -- ^ this is on by default, and I think it would be very confusing to stop treating “*” different from “Type” as this moment

-- these seem simple syntactic extensions -- many of them bring compatibility with the syntax of Java-like languages BinaryLiterals: yes HexFloatLiterals: yes NegativeLiterals: yes NumDecimals: yes NumericUnderscores: yes

-- too early but wouldn’t care to introduce it StandaloneKindSignatures: yes ImportQualifiedPost: yes

-- don’t know GHCForeignImportPrim: maybe InterruptibleFFI: maybe LexicalNegation: maybe NondecreasingIndentation: maybe PackageImports: maybe ParallelListComp: maybe TransformListComp: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe

-- the rest AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BangPatterns: yes BlockArguments: no CApiFFI: no CPP: no ConstraintKinds: yes DataKinds: yes DatatypeContexts: no DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes ExplicitForAll: yes ExplicitNamespaces: no ExtendedDefaultRules: no FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes -- ^ implied by GADTs anyway GADTs: yes GeneralisedNewtypeDeriving: yes ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InstanceSigs: yes KindSignatures: yes LambdaCase: yes LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MultiParamTypeClasses: yes NPlusKPatterns: no NamedFieldPuns: yes NoImplicitPrelude: no NoMonomorphismRestriction: yes NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: yes OverlappingInstances: no OverloadedLabels: no PolyKinds: yes PostfixOperators: yes QualifiedDo: no QuasiQuotes: no RebindableSyntax: no RecordWildCards: yes RecursiveDo: no RoleAnnotations: no Safe: no StandaloneDeriving: yes StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeFamilyDependencies: no TypeOperators: yes TypeSynonymInstances: yes UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no ViewPatterns: yes _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Ah yes, I meant to explain that I have a minor objection to the instances generated by EmptyDataDeriving. The Eq and Ord instances are defined for bottom inputs while Show is undefined, which is oddly inconsistent. If Eq and Ord forced their arguments I would have voted for including EmptyDataDeriving. Sent from my iPhone

On Dec 4, 2020, at 04:36, Joachim Breitner wrote:

Hi Eric,

probably not very relevant (both extensions far above the quorum) but it seems odd to include

...

EmptyDataDecls: yes

but then say

...

EmptyDataDeriving: no

Als note that the docs at https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.... say “The EmptyDataDeriving flag is only required to enable deriving of these four “standard” type classes (which are mentioned in the Haskell Report). Other extensions to the deriving mechanism, which are explained below in greater detail, do not require EmptyDataDeriving to be used in conjunction with empty data types.”

So enabling the other DerivingFoo extensions without EmptyDataDeriving is somewhat non-uniform.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

New votes (as of 7 December), I’ve changed ViewPatterns to ’no’. -- the ones with comments CUSKs: no -- ^ according to the guide, this is superseded by StandaloneKindSignatures ConstrainedClassMethods: yes -- ^ it is implied by MultiParamTypeClasses anyway DefaultSignatures: no -- ^ as Joachim says, this should be succeeded by DerivingVia -- ^ anyway, this is one required for the writer of the class, so no big deal DeriveAnyClass: no -- ^ given our discussion DerivingVia: no -- ^ too recent DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: yes -- ^ this is a hard one! I lean towards yes because they are guarded by its own syntax MonadFailDesugaring: yes -- ^ isn’t this the default nowadays? MonoLocalBinds: yes -- ^ this is implied by GADTs and TypeFamilies MultiWayIf: no -- ^ still in discussion NamedWildCards: yes -- ^ not many people use this, but I think this is the sane default OverloadedLists: yes OverloadedStrings: yes -- ^ I would love to see these included, but I agree with the sentiment that they need more work PartialTypeSignatures: no -- ^ I really think that partial type signatures should not be accepted by default QuantifiedConstraints: no -- ^ too early ScopedTypeVariables: yes -- ^ I think this is really well understood and people want it PatternSynonyms: maybe -- ^ we are still working out the edges of this ForeignFunctionInterface: yes RankNTypes: yes UnicodeSyntax: yes -- ^ following Joachim’s suggestion: enable this for syntax but *not* for error messages TypeInType: no -- ^ this simply implies PolyKinds, DataKinds, KindSignatures, according to the documentation StarIsType: yes -- ^ this is on by default, and I think it would be very confusing to stop treating “*” different from “Type” as this moment BlockArguments: no -- ^ too early ViewPatterns: no -- ^ the are better alternatives being proposed -- these seem simple syntactic extensions -- many of them bring compatibility with the syntax of Java-like languages BinaryLiterals: yes HexFloatLiterals: yes NegativeLiterals: yes NumDecimals: yes NumericUnderscores: yes -- too early but wouldn’t care to introduce it StandaloneKindSignatures: yes ImportQualifiedPost: yes -- don’t know GHCForeignImportPrim: maybe InterruptibleFFI: no LexicalNegation: maybe NondecreasingIndentation: maybe PackageImports: no ParallelListComp: no TransformListComp: no UnliftedFFITypes: no UnliftedNewtypes: no -- the rest AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BangPatterns: yes CApiFFI: no CPP: no ConstraintKinds: yes DataKinds: yes DatatypeContexts: no DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes ExplicitForAll: yes ExplicitNamespaces: no ExtendedDefaultRules: no FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes GADTs: yes GeneralisedNewtypeDeriving: yes ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InstanceSigs: yes KindSignatures: yes LambdaCase: yes LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MultiParamTypeClasses: yes NPlusKPatterns: no NamedFieldPuns: yes NoImplicitPrelude: no NoMonomorphismRestriction: yes NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: yes OverlappingInstances: no OverloadedLabels: no PolyKinds: yes PostfixOperators: yes QualifiedDo: no QuasiQuotes: no RebindableSyntax: no RecordWildCards: yes RecursiveDo: no RoleAnnotations: no Safe: no StandaloneDeriving: yes StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeFamilyDependencies: no TypeOperators: yes TypeSynonymInstances: yes UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no On 5 Dec 2020 at 21:42:22, Alejandro Serrano Mena wrote:

My new votes (as of 5 December):

Here are my new votes, after several discussions, and reading a bit about defaults (like for StarIsType) in the User Guide.

-- the ones with comments CUSKs: no -- ^ according to the guide, this is superseded by StandaloneKindSignatures ConstrainedClassMethods: yes -- ^ it is implied by MultiParamTypeClasses anyway DefaultSignatures: no -- ^ as Joachim says, this should be succeeded by DerivingVia -- ^ anyway, this is one required for the writer of the class, so no big deal DeriveAnyClass: no -- ^ given our discussion DerivingVia: no -- ^ too recent DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: yes -- ^ this is a hard one! I lean towards yes because they are guarded by its own syntax MonadFailDesugaring: yes -- ^ isn’t this the default nowadays? MonoLocalBinds: yes -- ^ this is implied by GADTs and TypeFamilies MultiWayIf: no -- ^ still in discussion NamedWildCards: yes -- ^ not many people use this, but I think this is the sane default OverloadedLists: yes OverloadedStrings: yes -- ^ I would love to see these included, but I agree with the sentiment that they need more work PartialTypeSignatures: no -- ^ I really think that partial type signatures should not be accepted by default QuantifiedConstraints: no -- ^ too early ScopedTypeVariables: yes -- ^ I think this is really well understood and people want it PatternSynonyms: maybe -- ^ we are still working out the edges of this ForeignFunctionInterface: yes RankNTypes: yes UnicodeSyntax: yes -- ^ following Joachim’s suggestion: enable this for syntax but *not* for error messages TypeInType: maybe -- ^ this simply implies PolyKinds, DataKinds, KindSignatures, according to the documentation StarIsType: yes -- ^ this is on by default, and I think it would be very confusing to stop treating “*” different from “Type” as this moment BlockArguments: no -- ^ too early

-- these seem simple syntactic extensions -- many of them bring compatibility with the syntax of Java-like languages BinaryLiterals: yes HexFloatLiterals: yes NegativeLiterals: yes NumDecimals: yes NumericUnderscores: yes

-- too early but wouldn’t care to introduce it StandaloneKindSignatures: yes ImportQualifiedPost: yes

-- don’t know GHCForeignImportPrim: maybe InterruptibleFFI: maybe LexicalNegation: maybe NondecreasingIndentation: maybe PackageImports: maybe ParallelListComp: maybe TransformListComp: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe

-- the rest AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BangPatterns: yes CApiFFI: no CPP: no ConstraintKinds: yes DataKinds: yes DatatypeContexts: no DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes ExplicitForAll: yes ExplicitNamespaces: no ExtendedDefaultRules: no FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes GADTs: yes GeneralisedNewtypeDeriving: yes ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InstanceSigs: yes KindSignatures: yes LambdaCase: yes LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MultiParamTypeClasses: yes NPlusKPatterns: no NamedFieldPuns: yes NoImplicitPrelude: no NoMonomorphismRestriction: yes NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: yes OverlappingInstances: no OverloadedLabels: no PolyKinds: yes PostfixOperators: yes QualifiedDo: no QuasiQuotes: no RebindableSyntax: no RecordWildCards: yes RecursiveDo: no RoleAnnotations: no Safe: no StandaloneDeriving: yes StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeFamilyDependencies: no TypeOperators: yes TypeSynonymInstances: yes UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no ViewPatterns: yes

Joachim, I love your statistics :) And I think I’m less sad that you made it look: I think that NullaryTypeClasses is implied by MultiParamTypeClasses, and that MonadFailDesugaring is already (or is going to be) the default in GHC! :P To get some more discussion, I would be very happy to hear reasons for and against: - GADTs: - Stable and well documented, - Adding indices to types is one of the main reasons one would like to have MultiParamTypeClasses and TypeFamilies on, - I find the GADT syntax much nicer (but this is an extremely personal choice.) - RankNTypes: - I originally voted “no”, because I find it to be part of “advanced Haskell”, and because using it may be complicated without ImpredicativeTypes on, - On the other hand, it’s also been in GHC for ages. On 3 Dec 2020 at 10:31:18, Joachim Breitner wrote:

Dear Committee,

we have 9 votes in. Dear Cale and Eric, can we have your votes please?

As always, the table

https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... has the current data.

We had the most discussion so far about:

* The innnocence of PostfixOperators * The effect of UnicodeSyntax on error messages * Whether InstanceSigs is a good design * Whether OverloadedString is harmless enough.

I see that three is less clear signal on odd extensions that are obsolete, on by default, implied by others etc. That’s probably fine and no need to worry; some of them will be resolved by virtue of being implied by others. We can also sanity-check the final result, and include all implied ones in the final design.

So where do we stand?

Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go in no matter how Cale and Eric vote:

BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, HexFloatLiterals, ImportQualifiedPost, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, StandaloneDeriving, ViewPatterns

The following have 6 or 7 votes, i.e. they’d go in if we extrapolate from the current votes:

ConstrainedClassMethods, DerivingStrategies, ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs, NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies, TypeOperators, TypeSynonymInstances

These extensions are short one vote:

DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds

So how sad would we all be? This is the sadness report for each committee member, showing the symmetric difference between their ballot and the (extrapolated) result.

alejandro would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses, NumDecimals, OverloadedLists, OverloadedStrings, PolyKinds, StandaloneKindSignatures doesn’t want: RankNTypes

arnaud would miss: Arrows, ExplicitNamespaces, ForeignFunctionInterface, FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds, PartialTypeSignatures, StarIsType, TypeFamilyDependencies doesn’t want: ExistentialQuantification, ImportQualifiedPost, InstanceSigs, NamedFieldPuns, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeSynonymInstances

iavor would miss: BlockArguments, MultiWayIf, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedStrings, ParallelListComp, RecursiveDo doesn’t want: ConstrainedClassMethods, ConstraintKinds, DeriveFoldable, DeriveFunctor, DeriveTraversable, DerivingStrategies, EmptyCase, GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures, NegativeLiterals, PostfixOperators, TupleSections, TypeApplications, TypeFamilies, TypeOperators

joachim would miss: DataKinds, DerivingVia, ForeignFunctionInterface, GADTs, LambdaCase, MonoLocalBinds, NamedWildCards, NondecreasingIndentation, RoleAnnotations, StarIsType, UnicodeSyntax, UnliftedFFITypes, UnliftedNewtypes doesn’t want: ConstrainedClassMethods, ScopedTypeVariables, TypeSynonymInstances

richard would miss: BlockArguments, DefaultSignatures, DerivingVia, DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation, NamedWildCards, NumDecimals, ParallelListComp, PolyKinds, RoleAnnotations, StandaloneKindSignatures, TemplateHaskellQuotes, UnicodeSyntax, UnliftedNewtypes doesn’t want: NegativeLiterals, RecordWildCards, ScopedTypeVariables, TypeFamilies

simonm would miss: DataKinds, DefaultSignatures, ForeignFunctionInterface, GADTs, LambdaCase, LiberalTypeSynonyms, MonoLocalBinds, MultiWayIf, NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals, OverloadedStrings, PatternSynonyms, PolyKinds, UnicodeSyntax doesn’t want: DeriveLift, DerivingStrategies, NumericUnderscores, TypeApplications, TypeOperators, ViewPatterns

spj would miss: MonoLocalBinds, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedLists, OverloadedStrings, ParallelListComp, PolyKinds, RecursiveDo, RoleAnnotations, StandaloneKindSignatures, StarIsType doesn’t want: DerivingStrategies, GeneralisedNewtypeDeriving, NegativeLiterals, RecordWildCards, TupleSections, TypeFamilies

tom would miss: BlockArguments, DataKinds, DefaultSignatures, DerivingVia, DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces, FunctionalDependencies, LambdaCase, LexicalNegation, LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards, NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp, PolyKinds, QuasiQuotes, RoleAnnotations, StandaloneKindSignatures, TemplateHaskell, TemplateHaskellQuotes, TypeFamilyDependencies, UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes doesn’t want: none!

vitaly would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, StarIsType doesn’t want: ConstrainedClassMethods, ExistentialQuantification, PostfixOperators

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My reservations around adding GADTs are really only reservations around MonoLocalBinds. However, as has been pointed out, TypeFamilies also implies MonoLocalBinds (this probably shouldn’t have been news to me), so I suppose I’d ought to go with both or neither! Given that choice, I think I’d rather add GADTs to my “yes” list than add TypeFamilies to my “no” list. Joachim, sorry to mess up your statistics again :) Cheers, Tom On 3 Dec 2020, at 10:03, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: GADTs must be one of Haskell’s most successful innovations ever. It’s a big feature, but it’s extremely well established now, and widely used. Users like GADTs – it’s #7 in the “popularity” column. Vote for GADTs 😊. Simon From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Alejandro Serrano Mena Sent: 03 December 2020 09:41 To: Joachim Breitner mailto:mail@joachim-breitner.de> Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status Joachim, I love your statistics :) And I think I’m less sad that you made it look: I think that NullaryTypeClasses is implied by MultiParamTypeClasses, and that MonadFailDesugaring is already (or is going to be) the default in GHC! :P To get some more discussion, I would be very happy to hear reasons for and against: - GADTs: - Stable and well documented, - Adding indices to types is one of the main reasons one would like to have MultiParamTypeClasses and TypeFamilies on, - I find the GADT syntax much nicer (but this is an extremely personal choice.) - RankNTypes: - I originally voted “no”, because I find it to be part of “advanced Haskell”, and because using it may be complicated without ImpredicativeTypes on, - On the other hand, it’s also been in GHC for ages. On 3 Dec 2020 at 10:31:18, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, we have 9 votes in. Dear Cale and Eric, can we have your votes please? As always, the table https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654681789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rzZgJlwbhSUTgZ2bRgSMRTZiArUtaKdzyCJAdpC2wWk%3D&reserved=0 has the current data. We had the most discussion so far about: * The innnocence of PostfixOperators * The effect of UnicodeSyntax on error messages * Whether InstanceSigs is a good design * Whether OverloadedString is harmless enough. I see that three is less clear signal on odd extensions that are obsolete, on by default, implied by others etc. That’s probably fine and no need to worry; some of them will be resolved by virtue of being implied by others. We can also sanity-check the final result, and include all implied ones in the final design. So where do we stand? Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go in no matter how Cale and Eric vote: BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, HexFloatLiterals, ImportQualifiedPost, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, StandaloneDeriving, ViewPatterns The following have 6 or 7 votes, i.e. they’d go in if we extrapolate from the current votes: ConstrainedClassMethods, DerivingStrategies, ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs, NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies, TypeOperators, TypeSynonymInstances These extensions are short one vote: DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds So how sad would we all be? This is the sadness report for each committee member, showing the symmetric difference between their ballot and the (extrapolated) result. alejandro would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses, NumDecimals, OverloadedLists, OverloadedStrings, PolyKinds, StandaloneKindSignatures doesn’t want: RankNTypes arnaud would miss: Arrows, ExplicitNamespaces, ForeignFunctionInterface, FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds, PartialTypeSignatures, StarIsType, TypeFamilyDependencies doesn’t want: ExistentialQuantification, ImportQualifiedPost, InstanceSigs, NamedFieldPuns, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeSynonymInstances iavor would miss: BlockArguments, MultiWayIf, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedStrings, ParallelListComp, RecursiveDo doesn’t want: ConstrainedClassMethods, ConstraintKinds, DeriveFoldable, DeriveFunctor, DeriveTraversable, DerivingStrategies, EmptyCase, GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures, NegativeLiterals, PostfixOperators, TupleSections, TypeApplications, TypeFamilies, TypeOperators joachim would miss: DataKinds, DerivingVia, ForeignFunctionInterface, GADTs, LambdaCase, MonoLocalBinds, NamedWildCards, NondecreasingIndentation, RoleAnnotations, StarIsType, UnicodeSyntax, UnliftedFFITypes, UnliftedNewtypes doesn’t want: ConstrainedClassMethods, ScopedTypeVariables, TypeSynonymInstances richard would miss: BlockArguments, DefaultSignatures, DerivingVia, DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation, NamedWildCards, NumDecimals, ParallelListComp, PolyKinds, RoleAnnotations, StandaloneKindSignatures, TemplateHaskellQuotes, UnicodeSyntax, UnliftedNewtypes doesn’t want: NegativeLiterals, RecordWildCards, ScopedTypeVariables, TypeFamilies simonm would miss: DataKinds, DefaultSignatures, ForeignFunctionInterface, GADTs, LambdaCase, LiberalTypeSynonyms, MonoLocalBinds, MultiWayIf, NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals, OverloadedStrings, PatternSynonyms, PolyKinds, UnicodeSyntax doesn’t want: DeriveLift, DerivingStrategies, NumericUnderscores, TypeApplications, TypeOperators, ViewPatterns spj would miss: MonoLocalBinds, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedLists, OverloadedStrings, ParallelListComp, PolyKinds, RecursiveDo, RoleAnnotations, StandaloneKindSignatures, StarIsType doesn’t want: DerivingStrategies, GeneralisedNewtypeDeriving, NegativeLiterals, RecordWildCards, TupleSections, TypeFamilies tom would miss: BlockArguments, DataKinds, DefaultSignatures, DerivingVia, DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces, FunctionalDependencies, LambdaCase, LexicalNegation, LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards, NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp, PolyKinds, QuasiQuotes, RoleAnnotations, StandaloneKindSignatures, TemplateHaskell, TemplateHaskellQuotes, TypeFamilyDependencies, UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes doesn’t want: none! vitaly would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, StarIsType doesn’t want: ConstrainedClassMethods, ExistentialQuantification, PostfixOperators -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5ZVahXxGFqEyoTMqj5ZitQaTKIIsSxu1G64gFcUFvjU%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdxLRYi8jFlwCdrXzDjvDw%2B098%2B9tRWvg6KJt7NT02I%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I voted against GADTs and am not yet inspired to change that vote: GADTs cause trouble for type inference. For example: Yes, but there is no prospect (that I know of) of a substantial improvement in this - and what we have does not seem to cause problems in practice. And they are jolly useful and popular! Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 03 December 2020 16:32 To: Alejandro Serrano Mena Cc: ghc-steering-committee@haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: - GADTs: - Stable and well documented, - Adding indices to types is one of the main reasons one would like to have MultiParamTypeClasses and TypeFamilies on, - I find the GADT syntax much nicer (but this is an extremely personal choice.) I voted against GADTs and am not yet inspired to change that vote: GADTs cause trouble for type inference. For example: data T a where MkT :: Int -> T a foo (MkT x) = x GHC can infer that foo :: T a -> Int. But if I change this to data T a where MkT :: Int -> T Int foo (MkT x) = x (where T is now a GADT) GHC can no longer infer my type. It complains about untouchable variables. This is a case of a "bad failure mode", where a simple error in input can lead to a very complicated error message in output. I thus think that users should knowledgeably opt into GADTs. Maybe if we had a much gentler error message in place here, I could be convinced otherwise. But, for now: Vote against GADTs! Richard PS: A counterpoint is RankNTypes, which I voted for. It would be hard to accidentally write a higher-rank type, and I find the error messages that arise are much clearer. Yes, it's an advanced feature, but one that is appropriately (in my opinion) gated in the code.

Hi, Am Donnerstag, den 03.12.2020, 09:20 -0800 schrieb Iavor Diatchki:

Joachim, would the voting system get a lot more complicated if we added a bit of ranked voting (e.g., instead of no,maybe,yes) we went (-2: strong reject, -1: reject, 0: don't care, 1: accept, 2: strong accept)? At least in my votes, I have a few extensions that I certainly feel strong about, and for some of them I just picked something but I don't really care either way, and I don't think that's captured in the votes. Let me know if that's OK, and I'll find some time to update my votes.

it would be doable, but the goal is not to do a tough campaigned vote to squeeze in the last extension that we can somehow claim has an arithmetic majority of some form. If you have a -2 on FooBar, (and are maybe not the alone against 10 who think it’s great), that alone should be sufficient to convince all of us that FooBar is not “harmless, useful and uncontentious”. That’s why I removed my vote for ViewPattern after I learned, from mails from the Simons, that it’s more contentious than I thought.

Also, I've been busy with work, so when there are a bunch of e-mails like today (which is fun!), it is hard to keep up with what people have said about the many threads going on. If we adopt the haddock like commenting system, would it be possible to scrape the e- mails and auto generate a summary of what people have said for various things? This could also help with a final document where we not only pick the extensions, but also have some provenance about what people thought about the various extensions.

Yes, I have been wondering the same. Overall, this “repeat your whole vote by mail system” is working, but not greatly so, and we’ll probably try something more ergonomic next time round. Maybe I'll throw together some regexes over the weekend. The latest votes are all at https://github.com/nomeata/ghc-proposals-stats/tree/master/ext-stats/GHC2021 if someone else wants to do some scraping. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones wrote:

Yes, but there is no prospect (that I know of) of a substantial improvement in [type inference for GADTs] – and what we have does not seem to cause problems in practice. And they are jolly useful and popular!

The problem I described would arise when someone who does not know about GADTs and type inference accidentally writes a GADT. But this cannot happen easily today, precisely because of the need to write the extension. Useful, popular, and stable all help argue for an extension (and I agree here!), but I'm more concerned about error messages and the beginner experience, captured in our Criterion 2 of https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh.... Richard

arnaud would miss: Arrows, ExplicitNamespaces, ForeignFunctionInterface, FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds, PartialTypeSignatures, StarIsType, TypeFamilyDependencies

Of these 10 extensions. Let me note that - ForeignFunctionInterface is part of Haskell 2010 - MonadFailDesugaring is the current default of GHC - MonoLocalBinds is implied by TypeFamilies, which is otherwise included So I assume that these are things which we've forgotten, rather than things that we oppose. On Fri, Dec 4, 2020 at 9:22 AM Spiwack, Arnaud wrote:

On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg wrote:

...

The problem I described would arise when someone who does not know about GADTs and type inference accidentally writes a GADT. But this cannot happen easily today, precisely because of the need to write the extension.

Useful, popular, and stable all help argue for an extension (and I agree here!), but I'm more concerned about error messages and the beginner experience, captured in our Criterion 2 of https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh... .

This is not a very believable objection in my opinion. GADTs are guarded by a different syntax which isn't used by someone who doesn't know about GADTs. So writing a GADT by accident is exceedingly unlikely. Besides, Ocaml has GADTs by default (with a similar syntax split as Haskell's). I don't believe I've ever heard anybody complain about GADTs since they've landed, certainly of anybody writing one by mistake.

Hi, Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow:

Right, we better be clear about ForeignFunctionInterface. Those who voted ForeignFunctionInterface: no, do you *really* want to turn off an extension that's already part of the Haskell standard?

In fact, the following extensions are implied by Haskell2010: ImplicitPrelude StarIsType CUSKs MonomorphismRestriction DatatypeContexts TraditionalRecordSyntax EmptyDataDecls ForeignFunctionInterface PatternGuards DoAndIfThenElse RelaxedPolyRec And the following non-Haskell2010 extensions are on by default (but not in Haskell2010 mode): NondecreasingIndentation NoDatatypeContexts I should have written the ballot consistently relative to Haskell2010, it’s a mixed bag right now, inherited from the survey. Or should it be relative to the GHC’s unnamed “default mode” (which is neither Haskell98 nor Haskell2010)? Anyways, one goal for GHC2021 is that it will subsume this unnamed default mode. So let’s see: Interesting ones: StarIsType -- ^ 5 votes. Those who voted no, did you do that knowing that it’s on by default these days? CUSKs -- ^ Legacy feature according to the docs, but the replacement StandaloneKindSignatures only has 50% votes so far. We probably need exactly one of the two. Both are new 8.10. MonomorphismRestriction -- ^ 4 votes. Those who voted no, did you do that knowing that it’s part of Haskell2010? (I admit I didn’t) ForeignFunctionInterface -- ^ 4 votes. Those who voted no, did you do that knowing that it’s part of Haskell2010? NondecreasingIndentation -- ^ Currently on by default, but off in Haskell2010 2 votes. Docs at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#co... Do we really want to turn it off? There must have been a good reason for GHC to have different default behavior so far? Boring ones: ImplicitPrelude -- ^ Obviously stays DatatypeContexts -- ^ 0 votes. This goes away. Yay! TraditionalRecordSyntax -- ^ NoTraditionalRecordSyntax has zero votes, so can stay EmptyDataDecls -- ^ 10 votes, so can stay PatternGuards -- ^ NoPatternGuards has zero votes, so can stay DoAndIfThenElse -- ^ wasn’t even on the ballot, probably a consequence of https://gitlab.haskell.org/ghc/ghc/-/issues/18631 I assume this stays unless someone disagrees. RelaxedPolyRec -- ^ Impossible to turn off, so this stays. Sorry for the confusion, next time round will be easier, when there is a clear base line (i.e. GHC2021). Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

In this case I think we should be a bit more conservative. There’s abundant documentation using “*” as the kind of ground types (people would often say “Maybe is a constructor of kind star to star”). We have to remember that we aim for GHC2021 to be the default language people use, so making a lot of information about Haskell obsolete seems like a very dangerous step here. As far as I know, the other extensions we have chosen just extend the language, but do not invalidate anything. Regards, Alejandro On 4 Dec 2020 at 12:07:33, Tom Harding wrote:

I can offer an answer RE StarIsType. While I know it’s currently the default, my understanding was that NoStarIsType was introduced as one of a series of steps to deprecate/discourage the use of * as something other than a regular binary operator. Given that, and the fact that GHC2021 is an extension I’d enable like any other (right?), I don’t think it’s necessarily a problem to include NoStarIsType. After all, the introduction of this extension won’t break any existing code (because it won’t be enabled) and it’s probably best to steer people (very gently) away from * ~ Type.

This decision obviously hinges on a couple of assumptions, and maybe this is a controversial opinion, but I don’t think it’s necessarily a bad thing to include this, even though it disagrees with the Haskell2010 spec.

Thanks, Tom

On 4 Dec 2020, at 10:57, Joachim Breitner wrote:

Hi,

Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow:

...

Right, we better be clear about ForeignFunctionInterface. Those who

...

voted ForeignFunctionInterface: no, do you *really* want to turn off

...

an extension that's already part of the Haskell standard?

In fact, the following extensions are implied by Haskell2010:

ImplicitPrelude

StarIsType

CUSKs

MonomorphismRestriction

DatatypeContexts

TraditionalRecordSyntax

EmptyDataDecls

ForeignFunctionInterface

PatternGuards

DoAndIfThenElse

RelaxedPolyRec

And the following non-Haskell2010 extensions are on by default (but not

in Haskell2010 mode):

NondecreasingIndentation

NoDatatypeContexts

I should have written the ballot consistently relative to Haskell2010,

it’s a mixed bag right now, inherited from the survey. Or should it be

relative to the GHC’s unnamed “default mode” (which is neither

Haskell98 nor Haskell2010)?

Anyways, one goal for GHC2021 is that it will subsume this unnamed

default mode.

So let’s see:

Interesting ones:

StarIsType

-- ^ 5 votes. Those who voted no, did you do that knowing

that it’s

on by default these days?

CUSKs

-- ^ Legacy feature according to the docs, but the replacement

StandaloneKindSignatures only has 50% votes so far.

We probably need exactly one of the two.

Both are new 8.10.

MonomorphismRestriction

-- ^ 4 votes. Those who voted no, did you do that knowing that it’s

part of Haskell2010? (I admit I didn’t)

ForeignFunctionInterface

-- ^ 4 votes. Those who voted no, did you do that knowing that it’s

part of Haskell2010?

NondecreasingIndentation

-- ^ Currently on by default, but off in Haskell2010

2 votes.

Docs at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#co...

Do we really want to turn it off? There must have been a good

reason for GHC to have different default behavior so far?

Boring ones:

ImplicitPrelude

-- ^ Obviously stays

DatatypeContexts

-- ^ 0 votes. This goes away. Yay!

TraditionalRecordSyntax

-- ^ NoTraditionalRecordSyntax has zero votes, so can stay

EmptyDataDecls

-- ^ 10 votes, so can stay

PatternGuards

-- ^ NoPatternGuards has zero votes, so can stay

DoAndIfThenElse

-- ^ wasn’t even on the ballot, probably a consequence of

https://gitlab.haskell.org/ghc/ghc/-/issues/18631

I assume this stays unless someone disagrees.

RelaxedPolyRec

-- ^ Impossible to turn off, so this stays.

Sorry for the confusion, next time round will be easier, when there is

a clear base line (i.e. GHC2021).

Cheers,

Joachim

--

Joachim Breitner

mail@joachim-breitner.de

http://www.joachim-breitner.de/

_______________________________________________

ghc-steering-committee mailing list

ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I hadn't seen this thread, sorry Alejandro, so let me copy my remarks from the main thread I would like to urge us not to include NoStarIsType in the defaults until

we include StandaloneKindSignature as well. Mostly on aesthetic grounds.

It's fairly obvious that NoStarIsType will be the default eventually. I just think that GHC2021 is premature.

On Fri, Dec 4, 2020 at 12:24 PM Tom Harding wrote:

I think this is an interesting question: is GHC2021 something that will, for example, just start appearing in a default cabal/stack file? Or, is it the long-awaited -XKitchenSink that I can just enable (explicitly) to imply this common/convenient set of extensions? If the former, I definitely agree - perhaps it’s not a good move. If the latter, these older tutorials/blogs won’t break because they won’t recommend turning on the extension. It’s also worth pointing out that the error is actually very good here:

...

:set -XNoStarIsType :kind *

<interactive>:1:1: error: Operator applied to too few arguments: * With NoStarIsType, ‘*’ is treated as a regular type operator. Did you mean to use ‘Type’ from Data.Kind instead?

Ultimately, though, if this extension *is* going to become a default in our tools rather than something that is opt-in, I absolutely agree - best not to break a wealth of resources for the sake of one extra line in my default-extensions list.

Cheers, Tom

On 4 Dec 2020, at 11:14, Alejandro Serrano Mena wrote:

In this case I think we should be a bit more conservative. There’s abundant documentation using “*” as the kind of ground types (people would often say “Maybe is a constructor of kind star to star”). We have to remember that we aim for GHC2021 to be the default language people use, so making a lot of information about Haskell obsolete seems like a very dangerous step here. As far as I know, the other extensions we have chosen just extend the language, but do not invalidate anything.

Regards, Alejandro

On 4 Dec 2020 at 12:07:33, Tom Harding wrote:

...

I can offer an answer RE StarIsType. While I know it’s currently the default, my understanding was that NoStarIsType was introduced as one of a series of steps to deprecate/discourage the use of * as something other than a regular binary operator. Given that, and the fact that GHC2021 is an extension I’d enable like any other (right?), I don’t think it’s necessarily a problem to include NoStarIsType. After all, the introduction of this extension won’t break any existing code (because it won’t be enabled) and it’s probably best to steer people (very gently) away from * ~ Type.

This decision obviously hinges on a couple of assumptions, and maybe this is a controversial opinion, but I don’t think it’s necessarily a bad thing to include this, even though it disagrees with the Haskell2010 spec.

Thanks, Tom

On 4 Dec 2020, at 10:57, Joachim Breitner wrote:

Hi,

Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow:

...

Right, we better be clear about ForeignFunctionInterface. Those who

...

voted ForeignFunctionInterface: no, do you *really* want to turn off

...

an extension that's already part of the Haskell standard?

In fact, the following extensions are implied by Haskell2010:

ImplicitPrelude

StarIsType

CUSKs

MonomorphismRestriction

DatatypeContexts

TraditionalRecordSyntax

EmptyDataDecls

ForeignFunctionInterface

PatternGuards

DoAndIfThenElse

RelaxedPolyRec

And the following non-Haskell2010 extensions are on by default (but not

in Haskell2010 mode):

NondecreasingIndentation

NoDatatypeContexts

I should have written the ballot consistently relative to Haskell2010,

it’s a mixed bag right now, inherited from the survey. Or should it be

relative to the GHC’s unnamed “default mode” (which is neither

Haskell98 nor Haskell2010)?

Anyways, one goal for GHC2021 is that it will subsume this unnamed

default mode.

So let’s see:

Interesting ones:

StarIsType

-- ^ 5 votes. Those who voted no, did you do that knowing

that it’s

on by default these days?

CUSKs

-- ^ Legacy feature according to the docs, but the replacement

StandaloneKindSignatures only has 50% votes so far.

We probably need exactly one of the two.

Both are new 8.10.

MonomorphismRestriction

-- ^ 4 votes. Those who voted no, did you do that knowing that it’s

part of Haskell2010? (I admit I didn’t)

ForeignFunctionInterface

-- ^ 4 votes. Those who voted no, did you do that knowing that it’s

part of Haskell2010?

NondecreasingIndentation

-- ^ Currently on by default, but off in Haskell2010

2 votes.

Docs at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#co...

Do we really want to turn it off? There must have been a good

reason for GHC to have different default behavior so far?

Boring ones:

ImplicitPrelude

-- ^ Obviously stays

DatatypeContexts

-- ^ 0 votes. This goes away. Yay!

TraditionalRecordSyntax

-- ^ NoTraditionalRecordSyntax has zero votes, so can stay

EmptyDataDecls

-- ^ 10 votes, so can stay

PatternGuards

-- ^ NoPatternGuards has zero votes, so can stay

DoAndIfThenElse

-- ^ wasn’t even on the ballot, probably a consequence of

https://gitlab.haskell.org/ghc/ghc/-/issues/18631

I assume this stays unless someone disagrees.

RelaxedPolyRec

-- ^ Impossible to turn off, so this stays.

Sorry for the confusion, next time round will be easier, when there is

a clear base line (i.e. GHC2021).

Cheers,

Joachim

--

Joachim Breitner

mail@joachim-breitner.de

http://www.joachim-breitner.de/

_______________________________________________

ghc-steering-committee mailing list

ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Freitag, den 04.12.2020, 11:07 +0000 schrieb Tom Harding:

After all, the introduction of this extension won’t break any existing code (because it won’t be enabled) and it’s probably best to steer people (very gently) away from * ~ Type.

This decision obviously hinges on a couple of assumptions, and maybe this is a controversial opinion, but I don’t think it’s necessarily a bad thing to include this, even though it disagrees with the Haskell2010 spec.

I strongly disagree. The goal of GHC2021 is, in my book, _not_ to change peoples behavior, and should only include uncontroversial, harmless extensions. Note that we want this to be the _default_ mode of GHC as well, so it may break existing non-cabalized scripts. So why getting people away from expecting and writing * may be a laudible goal, I’d be rather hesitant to use _this_ tool to achieve that. At least not without exposing Type in the prelude: Prelude> :set -XKindSignatures Prelude> :k Maybe Maybe :: * -> * Prelude> :k Maybe :: * -> * Maybe :: * -> * :: * -> * Prelude> :set -XNoStarIsType Prelude> :k Maybe Maybe :: Type -> Type Prelude> :k Maybe :: Type -> Type <interactive>:1:10: error: Not in scope: type constructor or class ‘Type’ <interactive>:1:18: error: Not in scope: type constructor or class ‘Type’ I find this too much of a _change_ (rather than a bunch of harmless opt-in extensions and corner case cleanups) to be eligible for GHC2021. I _could_ get behind a less drastic change, e.g. a -XStarCanBeType where GHC would by default print things using Type, have Type in scope by default (or print it with Data.Kind.Type), but also accept * as Type so that there is a nicer transition period. More careful nudging, less throat-forcing of this change. In any case, even if you think that GHC202x is the right tool to facilitate this change, then I recommend to not do it with GHC2021. Let's make GHC2021 smooth as butter for anyone, that it gets actually used with joy by most, and there is no community split because of it! Then we may have a better stand to carefully make controversial changes with GHC2022. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I also did not realize that GHC2021 was going to become the default behavior, and will change my vote against StarIsType. Is the expectation that GHC2021 remains the new default behavior, or will GHC2022 replace it as the default? I ask because tying these standards to GHC’s default behavior will make it much harder to correct mistakes or migrate to new designs of extensions (eg LambdaCase). Requiring an explicit opt-in to a GHC20XX standard means that users can upgrade to a new compiler and adapt to the new standard separately, which is very useful in larger enterprises. Sent from my iPhone

On Dec 4, 2020, at 06:30, Tom Harding wrote:

Ah, I see!

In which case, I wholly agree with you and Alejandro, and I’ll change my vote to a no - I had misunderstood this in my head as just being a more concise way to turn on a lot of extensions, rather than being a deliberate default that we intended to set for GHC. If new users would have to enable NoGHC2021 to get back to The Old Ways, then yes, it’s probably best not to contradict any of the current Haskell2010 defaults.

Thanks! Tom

...

On 4 Dec 2020, at 11:24, Joachim Breitner wrote:

Hi,

Am Freitag, den 04.12.2020, 11:07 +0000 schrieb Tom Harding:

...

After all, the introduction of this extension won’t break any existing code (because it won’t be enabled) and it’s probably best to steer people (very gently) away from * ~ Type.

This decision obviously hinges on a couple of assumptions, and maybe this is a controversial opinion, but I don’t think it’s necessarily a bad thing to include this, even though it disagrees with the Haskell2010 spec.

I strongly disagree. The goal of GHC2021 is, in my book, _not_ to change peoples behavior, and should only include uncontroversial, harmless extensions. Note that we want this to be the _default_ mode of GHC as well, so it may break existing non-cabalized scripts.

So why getting people away from expecting and writing * may be a laudible goal, I’d be rather hesitant to use _this_ tool to achieve that. At least not without exposing Type in the prelude:

Prelude> :set -XKindSignatures Prelude> :k Maybe Maybe :: * -> * Prelude> :k Maybe :: * -> * Maybe :: * -> * :: * -> *

Prelude> :set -XNoStarIsType Prelude> :k Maybe Maybe :: Type -> Type Prelude> :k Maybe :: Type -> Type

<interactive>:1:10: error: Not in scope: type constructor or class ‘Type’

<interactive>:1:18: error: Not in scope: type constructor or class ‘Type’

I find this too much of a _change_ (rather than a bunch of harmless opt-in extensions and corner case cleanups) to be eligible for GHC2021.

I _could_ get behind a less drastic change, e.g. a -XStarCanBeType where GHC would by default print things using Type, have Type in scope by default (or print it with Data.Kind.Type), but also accept * as Type so that there is a nicer transition period. More careful nudging, less throat-forcing of this change.

In any case, even if you think that GHC202x is the right tool to facilitate this change, then I recommend to not do it with GHC2021. Let's make GHC2021 smooth as butter for anyone, that it gets actually used with joy by most, and there is no community split because of it!

Then we may have a better stand to carefully make controversial changes with GHC2022.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

GHC seems to have a bit of an ambiguous take about defaults. For instance, `MonadFailDesugaring` is turned on since GHC 8.8 (or 8.10, I've been lost about these lately), regardless of whether you have selected a language in a Cabal file. It means that, as far as GHC is concerned, Haskell2010 means Haskell2010+MonadFailDesugaring (and a few friends). In this particular case, it is, of course, a reasonable assumption that we are not modifying the meaning of Haskell2010 to that extent (it's the whole point of shipping GHC2021 as an extension). I think it would be fair to set GHC2021 as the default language when launching, say ghci outside of a project. /Arnaud On Fri, Dec 4, 2020 at 1:41 PM Joachim Breitner wrote:

Hi,

Am Freitag, den 04.12.2020, 07:33 -0500 schrieb Eric Seidel:

...

Is the expectation that GHC2021 remains the new default behavior, or will GHC2022 replace it as the default? I ask because tying these standards to GHC’s default behavior will make it much harder to correct mistakes or migrate to new designs of extensions (eg LambdaCase). Requiring an explicit opt-in to a GHC20XX standard means that users can upgrade to a new compiler and adapt to the new standard separately, which is very useful in larger enterprises.

The use case you are describing (larger enterprises) probably mean you are using Cabal, which forces you to declare a default-language anyways. So that makes it opt-in, and all is well, I hope.

The “default” mode, as far as I know (please correct me if I am wrong) mainly applies to your one-shot script that you run, and of course interactive use in GHCI. Especially for the latter, I find it very appealing to have the full syntax without turning on extensions, hence my hope that the latest GHC202x is the default. And with these modes, some breakage is acceptable maybe.

Do others see this differently?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Fri, Dec 4, 2020 at 2:25 PM Eric Seidel wrote:

Do Bazel/Buck/etc reuse Cabal or do they reimplement the build themselves? I haven't used either (at Bloomberg we use cabal and stack, and good point about default-language, I forgot that was required), but my impression is that Bazel likes to reimplement everything so it can see precise dependencies, have granular caching, etc.

I don't know what the Buck Haskell support does. But in Bazel, you have a bit of both. The default behaviour is to build external dependencies with Cabal [1], and local files in pure Bazel [2]. By default, Bazel's rules_haskell will want to use GHC's defaults on your files. [1]: https://release.api.haskell.build/haskell/cabal.html#haskell_cabal_library [2]: https://release.api.haskell.build/haskell/defs.html#haskell_library

On Dec 4, 2020, at 10:29 AM, Joachim Breitner 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

Updated votes delta: - StandaloneKindSignatures: yes - StarIsType: yes ## Uncontroversial extensions 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: yes (changed to yes because it's needed to replace CUSKs) StarIsType: yes (changed to yes following discussion) ## 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

| that. At least not without exposing Type in the prelude I'm often annoyed by the need to import Data.Kind(Type). Exposing Type from the Prelude might be just the right thing. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 04 December 2020 11:24 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status | | Hi, | | Am Freitag, den 04.12.2020, 11:07 +0000 schrieb Tom Harding: | > After all, the introduction of this extension won’t break any | existing | > code (because it won’t be enabled) and it’s probably best to steer | > people (very gently) away from * ~ Type. | > | > This decision obviously hinges on a couple of assumptions, and maybe | > this is a controversial opinion, but I don’t think it’s necessarily | a | > bad thing to include this, even though it disagrees with the | > Haskell2010 spec. | | I strongly disagree. The goal of GHC2021 is, in my book, _not_ to | change peoples behavior, and should only include uncontroversial, | harmless extensions. Note that we want this to be the _default_ mode | of GHC as well, so it may break existing non-cabalized scripts. | | So why getting people away from expecting and writing * may be a | laudible goal, I’d be rather hesitant to use _this_ tool to achieve | that. At least not without exposing Type in the prelude: | | Prelude> :set -XKindSignatures | Prelude> :k Maybe | Maybe :: * -> * | Prelude> :k Maybe :: * -> * | Maybe :: * -> * :: * -> * | | Prelude> :set -XNoStarIsType | Prelude> :k Maybe | Maybe :: Type -> Type | Prelude> :k Maybe :: Type -> Type | | <interactive>:1:10: error: | Not in scope: type constructor or class ‘Type’ | | <interactive>:1:18: error: | Not in scope: type constructor or class ‘Type’ | | I find this too much of a _change_ (rather than a bunch of harmless | opt-in extensions and corner case cleanups) to be eligible for | GHC2021. | | | I _could_ get behind a less drastic change, e.g. a -XStarCanBeType | where GHC would by default print things using Type, have Type in | scope | by default (or print it with Data.Kind.Type), but also accept * as | Type | so that there is a nicer transition period. More careful nudging, | less | throat-forcing of this change. | | | In any case, even if you think that GHC202x is the right tool to | facilitate this change, then I recommend to not do it with GHC2021. | Let's make GHC2021 smooth as butter for anyone, that it gets | actually | used with joy by most, and there is no community split because of | it! | | Then we may have a better stand to carefully make controversial | changes | with GHC2022. | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da218 | 274565766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63 | 7426779203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=al%2FPwBdOBMsmI | v%2F7hH3ce%2BdPCKa9K6e%2BMtfRs2vteaY%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da21827456 | 5766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267 | 79203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DvDb4rRCvnRN%2BcqM4E | QSIf8kSXNypMnD6PZANjCENQI%3D&reserved=0

| CUSKs | -- ^ Legacy feature according to the docs, but the replacement | StandaloneKindSignatures only has 50% votes so far. | We probably need exactly one of the two. | Both are new 8.10. Let's *not* have CUSKs. We are trying to get rid of it... it'd be deeply strange to "bless" it in GHC2020. StandaloneKindSignatures is clearly the Right Thing. I'm sure we'll want it long term. It's a very graceful fit with PolyKinds. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 04 December 2020 10:57 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status | | Hi, | | Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow: | > Right, we better be clear about ForeignFunctionInterface. Those who | > voted ForeignFunctionInterface: no, do you *really* want to turn off | > an extension that's already part of the Haskell standard? | | In fact, the following extensions are implied by Haskell2010: | | ImplicitPrelude | StarIsType | CUSKs | MonomorphismRestriction | DatatypeContexts | TraditionalRecordSyntax | EmptyDataDecls | ForeignFunctionInterface | PatternGuards | DoAndIfThenElse | RelaxedPolyRec | | And the following non-Haskell2010 extensions are on by default (but | not in Haskell2010 mode): | | NondecreasingIndentation | NoDatatypeContexts | | I should have written the ballot consistently relative to Haskell2010, | it’s a mixed bag right now, inherited from the survey. Or should it be | relative to the GHC’s unnamed “default mode” (which is neither | Haskell98 nor Haskell2010)? | | Anyways, one goal for GHC2021 is that it will subsume this unnamed | default mode. | | | So let’s see: | | Interesting ones: | | StarIsType | -- ^ 5 votes. Those who voted no, did you do that knowing that it’s | on by default these days? | | CUSKs | -- ^ Legacy feature according to the docs, but the replacement | StandaloneKindSignatures only has 50% votes so far. | We probably need exactly one of the two. | Both are new 8.10. | | MonomorphismRestriction | -- ^ 4 votes. Those who voted no, did you do that knowing that it’s | part of Haskell2010? (I admit I didn’t) | | ForeignFunctionInterface | -- ^ 4 votes. Those who voted no, did you do that knowing that it’s | part of Haskell2010? | | NondecreasingIndentation | -- ^ Currently on by default, but off in Haskell2010 | 2 votes. | Docs at | https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownlo | ads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fbugs.htm | l%23context-free- | syntax&data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf874fa603 | d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267634 | 53649777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TyAnHPLdYOjeChFOF%2FMUa | zyP1%2BHhV2xjoPtxmSWS1CU%3D&reserved=0 | Do we really want to turn it off? There must have been a good | reason for GHC to have different default behavior so far? | | Boring ones: | | ImplicitPrelude | -- ^ Obviously stays | DatatypeContexts | -- ^ 0 votes. This goes away. Yay! | TraditionalRecordSyntax | -- ^ NoTraditionalRecordSyntax has zero votes, so can stay | EmptyDataDecls | -- ^ 10 votes, so can stay | PatternGuards | -- ^ NoPatternGuards has zero votes, so can stay DoAndIfThenElse | -- ^ wasn’t even on the ballot, probably a consequence of | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | ab.haskell.org%2Fghc%2Fghc%2F- | %2Fissues%2F18631&data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1f | caf874fa603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7 | C637426763453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj | oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BPYOFqz9V658 | 8IlquzjzcwAd8Oq9NbiOt86S2EG2Iq4%3D&reserved=0 | I assume this stays unless someone disagrees. | RelaxedPolyRec | -- ^ Impossible to turn off, so this stays. | | | Sorry for the confusion, next time round will be easier, when there is | a clear base line (i.e. GHC2021). | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf | 874fa603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63 | 7426763453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BKmPtIIneF9ke | 9RBN5VKFJ8a2pk16UOWA%2BOGOZ3zB7o%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf874fa | 603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267 | 63453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X44d0g%2Bd4rYDI86U1p | 3OQQC4E0b%2BzU2cpWfKj3h02VM%3D&reserved=0

I would be slightly sad to see ViewPatterns go in, for two reasons: (1) PatternSynonyms covers some of the use cases but by abstracting over data constructors, which doesn't require clients to adopt a non-idiomatic pattern matching style, and (2) for the rest of the use cases, IMO this design would be better: https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternativehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fview-patterns-alternative&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937668628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2FfeyRdjkJ17TtX2Ck9dP9MBrx%2BRMZxtTXoVKOLdShA%3D&reserved=0 I too much prefer this view-patterns-alternative rendering of view patterns. I suppose that someone should write a GHC proposal. But there would be some pain in switching from the existing view patterns to the new one. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 03 December 2020 11:26 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status I agree with Simon that we must have GADTs! I would be slightly sad to see ViewPatterns go in, for two reasons: (1) PatternSynonyms covers some of the use cases but by abstracting over data constructors, which doesn't require clients to adopt a non-idiomatic pattern matching style, and (2) for the rest of the use cases, IMO this design would be better: https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternativehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fview-patterns-alternative&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937668628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2FfeyRdjkJ17TtX2Ck9dP9MBrx%2BRMZxtTXoVKOLdShA%3D&reserved=0 Cheers Simon On Thu, 3 Dec 2020 at 09:31, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, we have 9 votes in. Dear Cale and Eric, can we have your votes please? As always, the table https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937678622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ph5AXJy8XnPZYxUzNly7ZlNjyHM0uVpNCud%2BqFxXk%2Fk%3D&reserved=0 has the current data. We had the most discussion so far about: * The innnocence of PostfixOperators * The effect of UnicodeSyntax on error messages * Whether InstanceSigs is a good design * Whether OverloadedString is harmless enough. I see that three is less clear signal on odd extensions that are obsolete, on by default, implied by others etc. That’s probably fine and no need to worry; some of them will be resolved by virtue of being implied by others. We can also sanity-check the final result, and include all implied ones in the final design. So where do we stand? Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go in no matter how Cale and Eric vote: BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, HexFloatLiterals, ImportQualifiedPost, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, StandaloneDeriving, ViewPatterns The following have 6 or 7 votes, i.e. they’d go in if we extrapolate from the current votes: ConstrainedClassMethods, DerivingStrategies, ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs, NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies, TypeOperators, TypeSynonymInstances These extensions are short one vote: DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds So how sad would we all be? This is the sadness report for each committee member, showing the symmetric difference between their ballot and the (extrapolated) result. alejandro would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses, NumDecimals, OverloadedLists, OverloadedStrings, PolyKinds, StandaloneKindSignatures doesn’t want: RankNTypes arnaud would miss: Arrows, ExplicitNamespaces, ForeignFunctionInterface, FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds, PartialTypeSignatures, StarIsType, TypeFamilyDependencies doesn’t want: ExistentialQuantification, ImportQualifiedPost, InstanceSigs, NamedFieldPuns, RankNTypes, RecordWildCards, ScopedTypeVariables, TupleSections, TypeSynonymInstances iavor would miss: BlockArguments, MultiWayIf, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedStrings, ParallelListComp, RecursiveDo doesn’t want: ConstrainedClassMethods, ConstraintKinds, DeriveFoldable, DeriveFunctor, DeriveTraversable, DerivingStrategies, EmptyCase, GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures, NegativeLiterals, PostfixOperators, TupleSections, TypeApplications, TypeFamilies, TypeOperators joachim would miss: DataKinds, DerivingVia, ForeignFunctionInterface, GADTs, LambdaCase, MonoLocalBinds, NamedWildCards, NondecreasingIndentation, RoleAnnotations, StarIsType, UnicodeSyntax, UnliftedFFITypes, UnliftedNewtypes doesn’t want: ConstrainedClassMethods, ScopedTypeVariables, TypeSynonymInstances richard would miss: BlockArguments, DefaultSignatures, DerivingVia, DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation, NamedWildCards, NumDecimals, ParallelListComp, PolyKinds, RoleAnnotations, StandaloneKindSignatures, TemplateHaskellQuotes, UnicodeSyntax, UnliftedNewtypes doesn’t want: NegativeLiterals, RecordWildCards, ScopedTypeVariables, TypeFamilies simonm would miss: DataKinds, DefaultSignatures, ForeignFunctionInterface, GADTs, LambdaCase, LiberalTypeSynonyms, MonoLocalBinds, MultiWayIf, NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals, OverloadedStrings, PatternSynonyms, PolyKinds, UnicodeSyntax doesn’t want: DeriveLift, DerivingStrategies, NumericUnderscores, TypeApplications, TypeOperators, ViewPatterns spj would miss: MonoLocalBinds, NoMonomorphismRestriction, NullaryTypeClasses, OverloadedLists, OverloadedStrings, ParallelListComp, PolyKinds, RecursiveDo, RoleAnnotations, StandaloneKindSignatures, StarIsType doesn’t want: DerivingStrategies, GeneralisedNewtypeDeriving, NegativeLiterals, RecordWildCards, TupleSections, TypeFamilies tom would miss: BlockArguments, DataKinds, DefaultSignatures, DerivingVia, DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces, FunctionalDependencies, LambdaCase, LexicalNegation, LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards, NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp, PolyKinds, QuasiQuotes, RoleAnnotations, StandaloneKindSignatures, TemplateHaskell, TemplateHaskellQuotes, TypeFamilyDependencies, UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes doesn’t want: none! vitaly would miss: DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, StarIsType doesn’t want: ConstrainedClassMethods, ExistentialQuantification, PostfixOperators -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937688618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SVEz3KOcsP0oBsVAuh08hXIKrnVlQQJvHaqddyv5GnI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937688618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z7%2FudmXrboJ9RKKn%2FAXDeknKC0EohWMY1hrzYUYuhJw%3D&reserved=0

On Thu, Dec 3, 2020, at 04:31, Joachim Breitner wrote:

Dear Committee,

we have 9 votes in. Dear Cale and Eric, can we have your votes please?

Sorry! I'll get them in tonight.

Hi Am Montag, den 07.12.2020, 21:16 +0100 schrieb Alejandro Serrano Mena:

- What should we do with those which are superseded? I voted ‘yes’ to NullaryTypeClasses because it’s implied by MultiParamTypeClasses. I don’t think we’ll end up in a situation in which the former is accepted but not the latter, but it’s worth mentioning.

my understanding is that implications will hold. So if we vote MultiParamTypeClasses in, but not NullaryTypeClasses explicitly then NullaryTypeClasses would still be active. Just as if you enabled -XMultiParamTypeClasses. Often, nothing else is technically possible. In fact, it makes sense to vote MultiParamTypeClasses: yes NullaryTypeClasses: no to express “I want MultiParamTypeClasses, but if that does not make it in, then NullaryTypeClasses isn't worth going in on its own”. In general, whatever set we end up with will still be under common sense scrutiny. I have briefly considered digging up the list of implications, and somehow including it in my updates (“the following extensions would be enabled by way of implication”). Maybe I’ll do that, we’ll see. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Updated votes, resolving all my maybes: Delta: * yes to NamedWildCards *and* PartialTypeSignatures (these are actually really useful and unless someone tells me otherwise I don't know any reason why the language with these is less principled than without. I would also -Wno-partial-type-signatures by default if that was in scope for GHC2021) * yes to TypeApplications (sure, why not) * all other maybes -> no (mainly just being conservative, we can reconsider for GHC2022 any that miss out) ## Uncontroversial extensions 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: yes (changed to yes because it's needed to replace CUSKs) StarIsType: yes (changed to yes following discussion) ## 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) Undecided (later resolved): AllowAmbiguousTypes: no TypeApplications: yes CApiFFI: no (harmless, but a bit niche) DerivingVia: no (not very widely-used, quite new) DerivingStrategies: no (not very widely-used, quite new) FunctionalDependencies: no (slightly inclined to "no", given the overlap with TypeFamilies and the lack of widespread usage) ExplicitNamespaces: no (might change, so defer?) MonadComprehensions: no (does this make error messages worse?) NamedWildCards: yes NumericUnderscores: no OverloadedLists: no (impact on error messages?) PartialTypeSignatures: yes RecursiveDo: no (but introduced by a keyword so relatively harmless) RoleAnnotations: no (not widely used, but when you need it you need it) TypeFamilyDependencies: no (not widely used, but when you need it you need it) TypeOperators: no On Mon, 7 Dec 2020 at 18:17, Joachim Breitner wrote:

Dear Committe,

it’s been two weeks since we started voting. We are still short one vote (Cale, release the suspsense!). But also, there are still plenty of “maybes” in your vote. I encourage you to change them to yes or no (at least for those extensions that are near the edge), so that we have more clarity on which extensions are actually worth spending emails on.

As always, the table

https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... has the current data. (And even even got community contributions to improve its readability. Yay!)

We discussed many extensions on (and I might have missed some):

* The innnocence of PostfixOperators was pointed out, and widely appreciated * Joachim pleads for UnicodeSyntax * InstanceSigs worries seems to have been addressed, it’s on its way in * Whether OverloadedString is harmless enough. * Whether ViewPatterns are good enough (given that alternative ideas exist) * That ForeignFunctionInterfaces is actually part of Haskell2010 * That this isn’t quite the right time to ditch StarIsType * CUSKs vs. StandaloneKindSignatures * BlockArguments is liked by some, but may be too new * GADTs were advocated for a lot, but also a bit against, so not uncontroversial * Same with ExistentialQuantification * PolyKinds were advocated for (and got many votes) * ScopedTypeVariables is wanted on by default by some, despite the fact that nobody believes it’s the last word on that design corner. Alejandro argues that it’s ok to include it even if it will change in GHC202X again, but elsewhere SPJ says that GHC2021 should only include extensions we have reason to hope are stable and stay around . * Arnaud wonders about the hesitation to include FunctionalDependencies

Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go in no matter how Cale votes:

BangPatterns, BinaryLiterals, ConstrainedClassMethods, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, TypeApplications, TypeOperators, TypeSynonymInstances

The following have 7 votes, which is the quorum based on 10 ballots:

ExistentialQuantification, ForeignFunctionInterface, MonoLocalBinds, NegativeLiterals, RecordWildCards, StandaloneKindSignatures, TypeFamilies

And these are one vote short:

DataKinds, DerivingStrategies, GADTs, NamedWildCards, ScopedTypeVariables, TupleSections, UnicodeSyntax, ViewPatterns

Not sure how useful the list of symmetric difference report is, but here it is:

alejandro would miss: DataKinds, DerivingStrategies, FunctionalDependencies, GADTs, LambdaCase, MonadFailDesugaring, NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses, NumDecimals, OverloadedLists, OverloadedStrings, ScopedTypeVariables, TupleSections, UnicodeSyntax, ViewPatterns doesn’t want: none!

arnaud would miss: Arrows, DerivingStrategies, ExplicitNamespaces, FunctionalDependencies, GADTs, MonadFailDesugaring, PartialTypeSignatures, TypeFamilyDependencies, ViewPatterns doesn’t want: ExistentialQuantification, ImportQualifiedPost, InstanceSigs, NamedFieldPuns, PolyKinds, RankNTypes, RecordWildCards, StandaloneKindSignatures, TypeSynonymInstances

eric would miss: DataKinds, DefaultSignatures, DisambiguateRecordFields, ExplicitNamespaces, FunctionalDependencies, GADTs, MonadFailDesugaring, NamedWildCards, OverloadedLists, OverloadedStrings, PartialTypeSignatures, PatternSynonyms, RoleAnnotations, ScopedTypeVariables, TypeFamilyDependencies doesn’t want: EmptyDataDeriving, ForeignFunctionInterface

iavor would miss: BlockArguments, CApiFFI, MultiWayIf, NoMonomorphismRestriction, NullaryTypeClasses, ParallelListComp, RecursiveDo, UnicodeSyntax, UnliftedNewtypes doesn’t want: ConstrainedClassMethods, EmptyCase, ExplicitForAll, GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures, MonoLocalBinds, NegativeLiterals, PolyKinds, StandaloneKindSignatures, StarIsType, TypeApplications, TypeFamilies, TypeOperators

joachim would miss: DataKinds, DerivingStrategies, DerivingVia, LambdaCase, NamedWildCards, NondecreasingIndentation, RoleAnnotations, TupleSections, UnicodeSyntax, UnliftedFFITypes, UnliftedNewtypes doesn’t want: ConstrainedClassMethods, ExistentialQuantification, TypeSynonymInstances

richard would miss: BlockArguments, DefaultSignatures, DerivingStrategies, DerivingVia, DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation, NamedWildCards, NumDecimals, ParallelListComp, RoleAnnotations, TemplateHaskellQuotes, TupleSections, UnicodeSyntax, UnliftedNewtypes, ViewPatterns doesn’t want: MonoLocalBinds, NegativeLiterals, RecordWildCards, TypeFamilies

simonm would miss: DataKinds, DefaultSignatures, GADTs, LambdaCase, LiberalTypeSynonyms, MultiWayIf, NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals, OverloadedStrings, PatternSynonyms, ScopedTypeVariables, TupleSections, UnicodeSyntax doesn’t want: DeriveLift, NumericUnderscores, TypeApplications, TypeOperators

spj would miss: NoMonomorphismRestriction, NullaryTypeClasses, OverloadedLists, OverloadedStrings, ParallelListComp, RecursiveDo, RoleAnnotations, ScopedTypeVariables, ViewPatterns doesn’t want: ForeignFunctionInterface, GeneralisedNewtypeDeriving, NegativeLiterals, RecordWildCards, TypeFamilies

tom would miss: BlockArguments, DataKinds, DefaultSignatures, DerivingStrategies, DerivingVia, DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces, FunctionalDependencies, GADTs, LambdaCase, LexicalNegation, LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards, NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp, QuasiQuotes, RoleAnnotations, ScopedTypeVariables, TemplateHaskell, TemplateHaskellQuotes, TupleSections, TypeFamilyDependencies, UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes, ViewPatterns doesn’t want: ForeignFunctionInterface, MonoLocalBinds, StarIsType

vitaly would miss: DataKinds, DerivingStrategies, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring, NamedWildCards, OverloadedLists, OverloadedStrings, ScopedTypeVariables, TupleSections, ViewPatterns doesn’t want: ExistentialQuantification, StandaloneKindSignatures

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I have been putting off doing any serious thinking about this until everyone's votes are in and we have can have a global overview of what it looks like. A long succession of plain text emails is hard to parse. Perhaps a wiki page where we can see a list of extensions that are: * Solidly in * Solidly out * Under debate Perhaps the third category has some structure e.g. some things that seem to belong together (all in or all out). I do think we should be conservative. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 09:22 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: Third week | starting | | Dear Committee, | | we are getting into the third week of voting. Still missing Cale’s | votes, but he promised to me off-band that he’ll work on it right now. | | Maybe not unsurprising, but while many of the 100-something decisions | we have signed up to make are clear, some are not. | | I am wondering a bit if ⅔ quorum was a bad choice, and a higher quota | would have put the critical line into a less contentious area. But | probably _any_ quorum causes plenty of discussions around the | extensions that are near that line. | | So how shall we continue? Simply stick to the process, have another | week of discussions, pleas and clarifications, maybe shift this or | that extension across the line, and then simply go with whatever we | have end of next Monday? | | Or should we continue discussions until there is pretty much consensus | about everything? (Probably won’t happen, though) | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C225202ff9f | 2349e6b4e408d8a011bf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435345381013055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=75V1dlj5UI4jtaC | bcrBARq%2F2lxWzxmaApT85U4HElIA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C225202ff9f2349e | 6b4e408d8a011bf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374353 | 45381013055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BV4gu6uHGXbkOn7aht | pRkh1pK%2BkYswQCi4CKr5whgpE%3D&reserved=0

| find the ones that are contentious. But it has less structure that | what you want, I think. Indeed so. It feels like data that can inform discussion rather than a direct basis for a debate. S | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 09:40 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: Third week | starting | | Hi, | | Am Montag, den 14.12.2020, 09:30 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > I have been putting off doing any serious thinking about this until | everyone's votes are in and we have can have a global overview of what | it looks like. A long succession of plain text emails is hard to | parse. | > | > Perhaps a wiki page where we can see a list of extensions that are: | > | > * Solidly in | > * Solidly out | > * Under debate | | as a first approximation, the table at the bottom of | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b654 | bf2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743 | 5356163845164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E0GKm1ODBAI1%2BdNV | 95TbOynJOZZNFvjshPsQtGPI28c%3D&reserved=0 | is kept up-to-date. e.g. Look at extensions with around 8 votes to | find the ones that are contentious. But it has less structure that | what you want, I think. | | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b | 654bf2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435356163855156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VjZ0WUERIIysxiP | xrxxh8coTa4SAHaXzJFstbXuzjVY%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b654bf | 2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374353 | 56163855156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tQZXP1BBC7R66QBdQu%2 | F5CR4NpuM%2Bd7X6GXOjGRPl9pA%3D&reserved=0

Hi, thanks! I’ve updated https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... and will send a status mail around shortly. Thinking about ways to address SPJs wish for a different discussion form. Am Montag, den 14.12.2020, 15:22 -0500 schrieb Cale Gibbard:

NumDecimals: no Not documented in a released GHC, so no. But what is this?

https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts....

TransformListComp: no I've never seen anyone put this to use.

Me neither! Until, because of this GHC2021 process, I was reminded of it, and, also because of this process, I had to do some data munging in GHCi. And I admit they are very handy for “Give me the names of the 20 most contentious extensions we have voted it:” *Main> mapM_ putStrLn [ ext | E{..} <- M.elems exts, votes >= 8, then sortOn by Down (fromIntegral survey_no / fromIntegral survey_yes), then take 5 ] PostfixOperators ConstrainedClassMethods TypeSynonymInstances ImportQualifiedPost NamedWildCards (Not arguing for their inclusion, this is just a nice anecodte.) *Main> mapM_ putStrLn [ ext | E{..} <- M.elems exts, votes >= 8, then sortOn by Down (fromIntegral survey_no / fromIntegral survey_yes), then take 5 ] <interactive>:15:80: warning: [-Wtype-defaults] • Defaulting the following constraints to type ‘Double’ (Fractional a0) arising from a use of ‘/’ at <interactive>:15:80-127 (Num a0) arising from a use of ‘fromIntegral’ at <interactive>:15:80-101 (Ord a0) arising from a use of ‘sortOn’ at <interactive>:15:64-69 • In the first argument of ‘Down’, namely ‘(fromIntegral survey_no / fromIntegral survey_yes)’ In the expression: Down (fromIntegral survey_no / fromIntegral survey_yes) In a stmt of a list comprehension: then sortOn by Down (fromIntegral survey_no / fromIntegral survey_yes) PostfixOperators ConstrainedClassMethods TypeSynonymInstances ImportQualifiedPost NamedWildCards Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I still have trouble seeing the big picture. Rather than complain I've made this Google doc to capture the state play. Another thing to keep up to date, and could be done on the same page as The Table. https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA... You all have edit rights. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | has the current data. | | Would it be helpful to add columns to that table for each committee | member? So that you can quickly see who voted what? | | The following in are safely in (= need more than one vote to change to | get out): | | BangPatterns, BinaryLiterals, ConstrainedClassMethods, | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, | TypeApplications, TypeSynonymInstances | | The following are barely in (exactly 8 votes in favor, and 3 against): | | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | I am sure we can have plenty of discussion for each of these. Probably | without end. As Simon says, mailing lists don't scale. So I think we | have two choices: | | 1. Let the numbers decide, and accept whatever comes out. According to | the process (which we should only follow if we find it helpful) we'd | maybe update our votes, and maybe point out new facets, for one week, | and then just take whatever has 8 votes. | | or | | 2. Explore a more efficient discussion format. | | For the latter I mentioned kialo.com before, and maybe it is worth a | try, so I set up a discussion there: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com%7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | So what do you see there? | | There is a discussion tree: | | The root is "what goes in GHC2021" | | The next layer are all extensions with 7 or 8 votes. | (I assume we should focus on those initially, but feel free to add | more or ask me to.) For example: TupleSections | | And then each of these has a column where we can collect Pros and | cons. | For example: | Pro: Opt-in Syntax | Con: Possible clash with extra-comma syntax extensions. | | So you can treat it like a wiki, but with structure to organize the | discussion. | | In fact, each pro and con is itself a node where you can add | supporting and disagreeing comments. This means that if you _disagree_ | that TupleSections are actually Opt-in syntax, there is a dedicated | place to raise that point, rather than putting "Not actually opt-in" | in the Con column of TupleSections... | | A good way to navigate the discussion seems to be the radial icon in | the top left; it opens a radial view of the whole discussion, and you | can read arguments by hovering. | | | The site doesn't offer voting, it is only about structuring the | discussion, and it is designed for much larger and much more | contentious debates (e.g. "Brexit"). So we'll see how well it works | for us and if it's helpful. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0

On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

Writing down the summary here

https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA...

allows me to ask:

* It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?

As far as I understand it, they have different purposes: - NamedWildCards instructs GHC to treat names starting with underscore as unknown variables when unifying. So for example, the following would not work, since _a would need to be Char and Bool at the same time.

f :: _a -> _a f ‘x’ = True

If you do not enable NamedWildCards, names starting with an underscore are taken to be regular variables. So the type ‘_a -> _a’ is completely equivalent to ‘a -> a’. - PartialTypeSignatures is about *accepting* those signatures by the compiler. If you don’t have this on, a partial type signature gives you an error with the inferred type, but does not continue compiling your program. Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | has the current data. | | Would it be helpful to add columns to that table for each committee | member? So that you can quickly see who voted what? | | The following in are safely in (= need more than one vote to change to | get out): | | BangPatterns, BinaryLiterals, ConstrainedClassMethods, | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, | TypeApplications, TypeSynonymInstances | | The following are barely in (exactly 8 votes in favor, and 3 against): | | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | I am sure we can have plenty of discussion for each of these. Probably | without end. As Simon says, mailing lists don't scale. So I think we | have two choices: | | 1. Let the numbers decide, and accept whatever comes out. According to | the process (which we should only follow if we find it helpful) we'd | maybe update our votes, and maybe point out new facets, for one week, | and then just take whatever has 8 votes. | | or | | 2. Explore a more efficient discussion format. | | For the latter I mentioned kialo.com before, and maybe it is worth a | try, so I set up a discussion there: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com%7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | So what do you see there? | | There is a discussion tree: | | The root is "what goes in GHC2021" | | The next layer are all extensions with 7 or 8 votes. | (I assume we should focus on those initially, but feel free to add | more or ask me to.) For example: TupleSections | | And then each of these has a column where we can collect Pros and | cons. | For example: | Pro: Opt-in Syntax | Con: Possible clash with extra-comma syntax extensions. | | So you can treat it like a wiki, but with structure to organize the | discussion. | | In fact, each pro and con is itself a node where you can add | supporting and disagreeing comments. This means that if you _disagree_ | that TupleSections are actually Opt-in syntax, there is a dedicated | place to raise that point, rather than putting "Not actually opt-in" | in the Con column of TupleSections... | | A good way to navigate the discussion seems to be the radial icon in | the top left; it opens a radial view of the whole discussion, and you | can read arguments by hovering. | | | The site doesn't offer voting, it is only about structuring the | discussion, and it is designed for much larger and much more | contentious debates (e.g. "Brexit"). So we'll see how well it works | for us and if it's helpful. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee wrote:

My point is that NamedWildcards is a souped up version of PartialTypeSignatures

f :: _ -> _

g :: _a -> _a

The former is a partial type signature. So is the latter! The former is equivalent to f :: _a -> _b.

Now, I’ve just discovered that

- Wildcards in types work **regardless** of flag. Thus you can use the above signature for f with no flag at all, and get a message like this:

Foo.hs:5:6: error:

• Found type wildcard ‘_’ standing for ‘[a]’

Where: ‘a’ is a rigid type variable bound by

the inferred type of f :: [a] -> [a]

at Foo.hs:6:1-12

To use the inferred type, enable PartialTypeSignatures

*So the only effect of PartialTypeSignatures is to turn that error into a warning.* I had not appreciated that.

- As you say, NamedWildCards treats _a as a wildcard rather than a variable. Fine.

- Given the above, I still think it’s bizarre not to allow PartialTypeSignatures. All the complexity is there already; it’s only a question of turning the error into a warning

It would be slightly strange to have a language feature that is enabled by default but generates a warning every time you use it. I'd rather the warning was disabled by default, but I agree that PartialTypeSignatures should be on. If I recall correctly, it was Richard who argued for NamedWildCards without PartialTypeSignatures (or independently of it), somewhere deep in one of these email threads :) Cheers Simon

-

Simon

*From:* Alejandro Serrano Mena *Sent:* 15 December 2020 12:48 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com

On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:

Writing down the summary here

https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977856035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nwXI1KIFwaFAf8WrdnXBF7MoNIhq2tTt0KIL0LVBCx8%3D&reserved=0

allows me to ask:

* It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?

As far as I understand it, they have different purposes:

- NamedWildCards instructs GHC to treat names starting with underscore as unknown variables when unifying. So for example, the following would not work, since _a would need to be Char and Bool at the same time.

...

f :: _a -> _a

...

f ‘x’ = True

If you do not enable NamedWildCards, names starting with an underscore are taken to be regular variables. So the type ‘_a -> _a’ is completely equivalent to ‘a -> a’.

- PartialTypeSignatures is about *accepting* those signatures by the compiler. If you don’t have this on, a partial type signature gives you an error with the inferred type, but does not continue compiling your program.

Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EHZIchQsOdwrT6p5MuQUoWONZvUr8x35ACzUXFZk1HA%3D&reserved=0 | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zmCppIBCXjqoVaZaXY1FWcKBcBBP8Pwni1jn7hkpBcU%3D&reserved=0 %2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977876027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yWWXXXYhlgsc6DkoQ2pl%2Fg3W3FKR6wrlSN70mYDCoWE%3D&reserved=0 %7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | has the current data. | | Would it be helpful to add columns to that table for each committee | member? So that you can quickly see who voted what? | | The following in are safely in (= need more than one vote to change to | get out): | | BangPatterns, BinaryLiterals, ConstrainedClassMethods, | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, | TypeApplications, TypeSynonymInstances | | The following are barely in (exactly 8 votes in favor, and 3 against): | | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | I am sure we can have plenty of discussion for each of these. Probably | without end. As Simon says, mailing lists don't scale. So I think we | have two choices: | | 1. Let the numbers decide, and accept whatever comes out. According to | the process (which we should only follow if we find it helpful) we'd | maybe update our votes, and maybe point out new facets, for one week, | and then just take whatever has 8 votes. | | or | | 2. Explore a more efficient discussion format. | | For the latter I mentioned kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0 before, and maybe it is worth a | try, so I set up a discussion there: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0 %2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gNhldU3ky0zZjdTamtkGkcXkYnij%2FnZfXZP%2FVA7pBh4%3D&reserved=0 %7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | So what do you see there? | | There is a discussion tree: | | The root is "what goes in GHC2021" | | The next layer are all extensions with 7 or 8 votes. | (I assume we should focus on those initially, but feel free to add | more or ask me to.) For example: TupleSections | | And then each of these has a column where we can collect Pros and | cons. | For example: | Pro: Opt-in Syntax | Con: Possible clash with extra-comma syntax extensions. | | So you can treat it like a wiki, but with structure to organize the | discussion. | | In fact, each pro and con is itself a node where you can add | supporting and disagreeing comments. This means that if you _disagree_ | that TupleSections are actually Opt-in syntax, there is a dedicated | place to raise that point, rather than putting "Not actually opt-in" | in the Con column of TupleSections... | | A good way to navigate the discussion seems to be the radial icon in | the top left; it opens a radial view of the whole discussion, and you | can read arguments by hovering. | | | The site doesn't offer voting, it is only about structuring the | discussion, and it is designed for much larger and much more | contentious debates (e.g. "Brexit"). So we'll see how well it works | for us and if it's helpful. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gDY7g2ZbZUXmBOcZ965QbDXx%2FyqV0QTzLy28JY6PnTI%3D&reserved=0 %2F&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977906015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=um%2Ba0XdBybuyBixCbfruJUGQRyHy%2BBaXDGbgFWIAu2k%3D&reserved=0 %7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiZXGZCSRr4RgU0zb3UtblBFxJYUeM%2B8JBZ6goNbQsY%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o9BSWTudDLBqHILOY4c52gYrO7col9hS5OcJ6JTDT1k%3D&reserved=0 %7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977926004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iS6WeND3u5ArOZHO2KRvfEe1gV9%2BySwH%2BaeJbZQtMhg%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I just tried Kialo, and couldn't warm to it -- despite being excited to try. + I really like its way of encouraging individual pros and cons, and how these are kept short and independent. - I can't get *any* forest, only lots and lots of trees. Kialo forces focus on only one thing at a time, but I found myself constantly losing any picture of where I was or where I was going. - There seems to be no visual indication (to me) of when a node has sub-nodes. For example, if I read a "con" that itself has 5 "cons" underneath, I wouldn't know unless I click on it. - I think I stumbled into a con of a con of a con. See "I found myself constantly losing any picture of where I was", above. - There doesn't seem to be a way to agree with an argument, without adding a distinct "pro". This means that if a post is liked by 8 of us and disliked (for different reasons) by 3, there would be 3 cons against it, no pros, and a misrepresentation of our communal opinion. In its current form, Kialo seems best as a way to organize pros and cons, but to actually have debate elsewhere. If someone out there knows how to mitigate the cons above, I'd be interested. If Kialo becomes the place where the action is, I'll participate, but I would hope there's a better way. (Not that email threads are necessarily better!) Richard

On Dec 15, 2020, at 3:27 PM, Simon Marlow wrote:

On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: My point is that NamedWildcards is a souped up version of PartialTypeSignatures

f :: _ -> _

g :: _a -> _a

The former is a partial type signature. So is the latter! The former is equivalent to f :: _a -> _b.

Now, I’ve just discovered that

Wildcards in types work *regardless* of flag. Thus you can use the above signature for f with no flag at all, and get a message like this: Foo.hs:5:6: error:

• Found type wildcard ‘_’ standing for ‘[a]’

Where: ‘a’ is a rigid type variable bound by

the inferred type of f :: [a] -> [a]

at Foo.hs:6:1-12

To use the inferred type, enable PartialTypeSignatures

So the only effect of PartialTypeSignatures is to turn that error into a warning. I had not appreciated that.

As you say, NamedWildCards treats _a as a wildcard rather than a variable. Fine.

Given the above, I still think it’s bizarre not to allow PartialTypeSignatures. All the complexity is there already; it’s only a question of turning the error into a warning

It would be slightly strange to have a language feature that is enabled by default but generates a warning every time you use it. I'd rather the warning was disabled by default, but I agree that PartialTypeSignatures should be on.

If I recall correctly, it was Richard who argued for NamedWildCards without PartialTypeSignatures (or independently of it), somewhere deep in one of these email threads :)

Cheers Simon

Simon

From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 15 December 2020 12:48 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Joachim Breitner mailto:mail@joachim-breitner.de>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com http://kialo.com/

On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

Writing down the summary here https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977856035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nwXI1KIFwaFAf8WrdnXBF7MoNIhq2tTt0KIL0LVBCx8%3D&reserved=0

allows me to ask:

* It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?

As far as I understand it, they have different purposes:

- NamedWildCards instructs GHC to treat names starting with underscore as unknown variables when unifying. So for example, the following would not work, since _a would need to be Char and Bool at the same time.

...

f :: _a -> _a

...

f ‘x’ = True

If you do not enable NamedWildCards, names starting with an underscore are taken to be regular variables. So the type ‘_a -> _a’ is completely equivalent to ‘a -> a’.

- PartialTypeSignatures is about *accepting* those signatures by the compiler. If you don’t have this on, a partial type signature gives you an error with the inferred type, but does not continue compiling your program.

Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EHZIchQsOdwrT6p5MuQUoWONZvUr8x35ACzUXFZk1HA%3D&reserved=0 | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zmCppIBCXjqoVaZaXY1FWcKBcBBP8Pwni1jn7hkpBcU%3D&reserved=0%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977876027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yWWXXXYhlgsc6DkoQ2pl%2Fg3W3FKR6wrlSN70mYDCoWE%3D&reserved=0%7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | has the current data. | | Would it be helpful to add columns to that table for each committee | member? So that you can quickly see who voted what? | | The following in are safely in (= need more than one vote to change to | get out): | | BangPatterns, BinaryLiterals, ConstrainedClassMethods, | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, | TypeApplications, TypeSynonymInstances | | The following are barely in (exactly 8 votes in favor, and 3 against): | | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | I am sure we can have plenty of discussion for each of these. Probably | without end. As Simon says, mailing lists don't scale. So I think we | have two choices: | | 1. Let the numbers decide, and accept whatever comes out. According to | the process (which we should only follow if we find it helpful) we'd | maybe update our votes, and maybe point out new facets, for one week, | and then just take whatever has 8 votes. | | or | | 2. Explore a more efficient discussion format. | | For the latter I mentioned kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0 before, and maybe it is worth a | try, so I set up a discussion there: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gNhldU3ky0zZjdTamtkGkcXkYnij%2FnZfXZP%2FVA7pBh4%3D&reserved=0%7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | So what do you see there? | | There is a discussion tree: | | The root is "what goes in GHC2021" | | The next layer are all extensions with 7 or 8 votes. | (I assume we should focus on those initially, but feel free to add | more or ask me to.) For example: TupleSections | | And then each of these has a column where we can collect Pros and | cons. | For example: | Pro: Opt-in Syntax | Con: Possible clash with extra-comma syntax extensions. | | So you can treat it like a wiki, but with structure to organize the | discussion. | | In fact, each pro and con is itself a node where you can add | supporting and disagreeing comments. This means that if you _disagree_ | that TupleSections are actually Opt-in syntax, there is a dedicated | place to raise that point, rather than putting "Not actually opt-in" | in the Con column of TupleSections... | | A good way to navigate the discussion seems to be the radial icon in | the top left; it opens a radial view of the whole discussion, and you | can read arguments by hovering. | | | The site doesn't offer voting, it is only about structuring the | discussion, and it is designed for much larger and much more | contentious debates (e.g. "Brexit"). So we'll see how well it works | for us and if it's helpful. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de mailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gDY7g2ZbZUXmBOcZ965QbDXx%2FyqV0QTzLy28JY6PnTI%3D&reserved=0%2F&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977906015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=um%2Ba0XdBybuyBixCbfruJUGQRyHy%2BBaXDGbgFWIAu2k%3D&reserved=0%7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiZXGZCSRr4RgU0zb3UtblBFxJYUeM%2B8JBZ6goNbQsY%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o9BSWTudDLBqHILOY4c52gYrO7col9hS5OcJ6JTDT1k%3D&reserved=0%7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977926004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iS6WeND3u5ArOZHO2KRvfEe1gV9%2BySwH%2BaeJbZQtMhg%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Mittwoch, den 16.12.2020, 09:20 +0100 schrieb Joachim Breitner:

- There doesn't seem to be a way to agree with an argument, without

...

adding a distinct "pro". This means that if a post is liked by 8 of us and disliked (for different reasons) by 3, there would be 3 cons against it, no pros, and a misrepresentation of our communal opinion.

It’s not a voting tool. It is a way to map out the arguments, and (maybe) more easily appreciate and take in the facets of the discussion than other forms.

That said, Kialo has an optional “voting” feature, where you can rate the “impact” of each claim (i.e. how strongly a pro or con claim affects its parent claim). https://support.kialo.com/hc/en-us/articles/115000705652-About-Voting I’ll enable it, maybe it’s useful.

Enabled it now. It allows you to rate the impact (i.e. relevance and truth) of a claim on its parent claim, and the UI will then order claims by relevance. So it isn’t voting in the sense of “now a slight majority overrules a small minority to create facts” (for that we still use our email ballots), but a way to add more refined signal to the view on the debate that Kialo provides: The most relevant pros and cons are now highlighted, and claims that are not convincing are de-emphasized. There is no need to vote on everything, of course. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Thu, 17 Dec 2020 at 09:21, Spiwack, Arnaud wrote:

On Tue, Dec 15, 2020 at 9:28 PM Simon Marlow wrote:

...

It would be slightly strange to have a language feature that is enabled by default but generates a warning every time you use it. I'd rather the warning was disabled by default, but I agree that PartialTypeSignatures should be on.

I'm not sure what warning is “on by default”, as I always have at least `-Wall` turned on all the time.

The warnings that are on by default are listed here: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/using-warning... (note -Wpartial-type-signatures is included)

But isn't every instance of a warning a case of “a feature that is enabled by default but generates a warning”? Name shadowing is one such. So is incomplete pattern matching.

What I mean, I guess, is that every warning could be an error if we so

desired, couldn't they? What's special about this one?

In the case of partial type signatures *you can't use the feature without generating a warning*, which is quite a different matter, I think. It would be even stranger if it was an error! Cheers Simon

On Thu, 17 Dec 2020 at 16:42, Spiwack, Arnaud wrote:

On Thu, Dec 17, 2020 at 5:24 PM Simon Marlow marlowsd@gmail.com http://mailto:marlowsd@gmail.com wrote:

...

In the case of partial type signatures *you can't use the feature without generating a warning*, which is quite a different matter, I think. It would be even stranger if it was an error!

I’m not sure I follow, I can certainly use PartialTypeSignature without generating a warning:

...

:set -XPartialTypeSignatures :set -Wno-partial-type-signatures f :: _ -> _ ; f = (+) 1

You disabled the warning!

I'm sorry I'm not making this point very well, let me try to clarify. I'm saying that it would be strange to enable PartialTypeSignatures by default *and* leave the warning turned on by default, because it would be impossible to use the feature without generating a warning (unless of course you disable the warning explicitly, but it's silly to have to do that just to use a feature that is enabled by default). It would be fine to leave the extension disabled, or better (in my view) to enable the extension and disable the warning. Cheers Simon

Unless you are saying that the feature *is* the warning. Which is debatable.

If you think that the warning is the feature, though, then you have the same feature without PartialTypeSignature, but as an error instead

...

f :: _ -> _ ; f = (+) 1

<interactive>:2:6: error: * Found type wildcard `_' standing for `Integer' To use the inferred type, enable PartialTypeSignatures * In the type `_ -> _' In the type signature: f :: _ -> _

<interactive>:2:11: error: * Found type wildcard `_' standing for `Integer' To use the inferred type, enable PartialTypeSignatures * In the type `_ -> _' In the type signature: f :: _ -> _

Trying Kialo. Joachim and Iavor write pros for existential quantification that I don't understand. I tried "suggest improvement", but those suggestions are invisible unless you relally drill down. SImon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | has the current data. | | Would it be helpful to add columns to that table for each committee | member? So that you can quickly see who voted what? | | The following in are safely in (= need more than one vote to change to | get out): | | BangPatterns, BinaryLiterals, ConstrainedClassMethods, | ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, | DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, | FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, | MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, | PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, | TypeApplications, TypeSynonymInstances | | The following are barely in (exactly 8 votes in favor, and 3 against): | | ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | I am sure we can have plenty of discussion for each of these. Probably | without end. As Simon says, mailing lists don't scale. So I think we | have two choices: | | 1. Let the numbers decide, and accept whatever comes out. According to | the process (which we should only follow if we find it helpful) we'd | maybe update our votes, and maybe point out new facets, for one week, | and then just take whatever has 8 votes. | | or | | 2. Explore a more efficient discussion format. | | For the latter I mentioned kialo.com before, and maybe it is worth a | try, so I set up a discussion there: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com%7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | So what do you see there? | | There is a discussion tree: | | The root is "what goes in GHC2021" | | The next layer are all extensions with 7 or 8 votes. | (I assume we should focus on those initially, but feel free to add | more or ask me to.) For example: TupleSections | | And then each of these has a column where we can collect Pros and | cons. | For example: | Pro: Opt-in Syntax | Con: Possible clash with extra-comma syntax extensions. | | So you can treat it like a wiki, but with structure to organize the | discussion. | | In fact, each pro and con is itself a node where you can add | supporting and disagreeing comments. This means that if you _disagree_ | that TupleSections are actually Opt-in syntax, there is a dedicated | place to raise that point, rather than putting "Not actually opt-in" | in the Con column of TupleSections... | | A good way to navigate the discussion seems to be the radial icon in | the top left; it opens a radial view of the whole discussion, and you | can read arguments by hovering. | | | The site doesn't offer voting, it is only about structuring the | discussion, and it is designed for much larger and much more | contentious debates (e.g. "Brexit"). So we'll see how well it works | for us and if it's helpful. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0

Dear Committee We're in danger of actually *removing* an extension from the default set of extensions that is enabled in GHC, which is not what I understood GHC2021 was all about. And it's not because anyone (at least as far as I know) actually thinks that ForeignFunctionInterface is a bad idea and should be deprecated or replaced. What other reasons could there be for turning off an extension that has been on by default for so many years? ForeignFunctionInterface is part of Haskell2010. Are we saying we disagree with the decision to make it a part of the language standard? I hope not! Please let's think very hard before doing this! Cheers Simon On Mon, 14 Dec 2020 at 22:22, Joachim Breitner wrote:

Dear Committe,

three weeks in, we have all votes. So now things are looking more concrete.

As always, the table

https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... has the current data.

Would it be helpful to add columns to that table for each committee member? So that you can quickly see who voted what?

The following in are safely in (= need more than one vote to change to get out):

BangPatterns, BinaryLiterals, ConstrainedClassMethods, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, TypeApplications, TypeSynonymInstances

The following are barely in (exactly 8 votes in favor, and 3 against):

ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, TypeOperators

The following are short one vote (7 in favor, 4 against):

DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, TypeFamilies

I am sure we can have plenty of discussion for each of these. Probably without end. As Simon says, mailing lists don't scale. So I think we have two choices:

1. Let the numbers decide, and accept whatever comes out. According to the process (which we should only follow if we find it helpful) we’d maybe update our votes, and maybe point out new facets, for one week, and then just take whatever has 8 votes.

or

2. Explore a more efficient discussion format.

For the latter I mentioned kialo.com before, and maybe it is worth a try, so I set up a discussion there:

https://www.kialo.com/which-haskell-extensions-should-go-into-ghc2021-43548?...

So what do you see there?

There is a discussion tree:

The root is “what goes in GHC2021”

The next layer are all extensions with 7 or 8 votes. (I assume we should focus on those initially, but feel free to add more or ask me to.) For example: TupleSections

And then each of these has a column where we can collect Pros and cons. For example: Pro: Opt-in Syntax Con: Possible clash with extra-comma syntax extensions.

So you can treat it like a wiki, but with structure to organize the discussion.

In fact, each pro and con is itself a node where you can add supporting and disagreeing comments. This means that if you _disagree_ that TupleSections are actually Opt-in syntax, there is a dedicated place to raise that point, rather than putting “Not actually opt-in” in the Con column of TupleSections…

A good way to navigate the discussion seems to be the radial icon in the top left; it opens a radial view of the whole discussion, and you can read arguments by hovering.

The site doesn't offer voting, it is only about structuring the discussion, and it is designed for much larger and much more contentious debates (e.g. “Brexit”). So we’ll see how well it works for us and if it’s helpful.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Donnerstag, den 17.12.2020, 09:19 -0800 schrieb Iavor Diatchki:

I updated my vote to "yes" (I hope, it's a bit hard to see the votes).

see column ID on https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... you have a ✓ next to ForeignFunctionInterface, so your vote is counted. We don't have a ✓ from Cale, Eric, SPJ. I assume none of them actually want to remove something from Haskell2010, but it doesn't hurt to clarify – after all SPJ writes

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`

so maybe this _is_ a proposal to make FFI extension-guarded, even though it wasn't in Haskell2010? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

| clarify – after all SPJ writes | | > 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` I didn't actually write that -- I just copied it from Iavor without thinking carefully enough. I agree we should not remove it. Plus change my vote for FFI to yes. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 17 December 2020 17:31 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] A plea for | ForeignFunctionInterface | | Hi, | | Am Donnerstag, den 17.12.2020, 09:19 -0800 schrieb Iavor Diatchki: | > I updated my vote to "yes" (I hope, it's a bit hard to see the | votes). | | see column ID on | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438504 | da9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743 | 8231073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ytdAFFyUzw42q4CCTc | gReYA7L4aR1vmwyxi6Tw8J92w%3D&reserved=0 | you have a ✓ next to ForeignFunctionInterface, so your vote is | counted. | | We don't have a ✓ from Cale, Eric, SPJ. I assume none of them actually | want to remove something from Haskell2010, but it doesn't hurt to | clarify – after all SPJ writes | | > 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` | | so maybe this _is_ a proposal to make FFI extension-guarded, even | though it wasn't in Haskell2010? | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438 | 504da9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7438231073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8APGVhhAgaiyMJU | bMPULTeXMxw0iI1TR88S4A6O7Q4A%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438504da | 9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374382 | 31073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0jakyN5fn6rE1MNnEpGE | iQBtyL695b1aH48%2BEKyi%2B80%3D&reserved=0

In my experience, FFI is the kind of extension that you want to isolate to a single module, and like Cale (or Iavor with the fancier type system extensions) I like the indicator at the top of the file that this module will be dealing with FFI concerns. In that sense, FFI feels a lot like MagicHash to me, a very important and useful extension, but one that you don't want (or at least don't *need*) enabled everywhere. So it's interesting to me that while FFI has 8 votes now, MagicHash (and UnboxedTuples and UnboxedSums) only has a single vote. I don't see excluding FFI from GHC2021 as an argument that it should be avoided or deprecated, just that it's not a part of the every day Haskell toolkit. I think it deserves to continue to be part of the Haskell standard, but is also niche enough to warrant selective enablement where it's needed. In other words, I think it would be perfectly fine if the Haskell standard mandated FFI as an extension that could be enabled on demand (in fact this is how I thought it worked when I first learned that FFI was included in Haskell2010). That all said, there's clearly nothing wrong with enabling it universally, it's been the default for a while and hasn't caused any problems I'm aware of. So if Simon M and others feel strongly about including FFI, I don't want to stand in the way. But I am curious why we shouldn't include the other parts of the low-level Haskell toolkit as well. Eric

On Dec 17, 2020, at 11:47, Cale Gibbard wrote:

My impression of the GHC2021 thing was that it's an arbitrary collection of extensions that would make for a sensible default, rather than something that was in any way tied to a standardisation process.

ForeignFunctionInterface is obviously not going anywhere, but also, its use is generally confined to particular modules, where the {-# Language ForeignFunctionInterface #-} pragma at the top would be good documentation for what sort of module we're about to see. I was also slightly concerned that switching that on may have an impact on overall compiler performance, seeing as it may need to interact with the driver in more ways than most extensions, but I don't really know and haven't yet done any testing.

I also had no idea it was turned on by default in Haskell2010, though I'm not sure it matters all that much what was turned on in Haskell2010 for these purposes either?

That said, I could go either way on this one.

If we're going to turn FFI on, why not throw in all the other extensions to FFI? Given that they introduce their own bits of syntax, so could hardly affect anything by accident, I think it would be appropriate.

On Thu, 17 Dec 2020 at 11:40, Simon Marlow wrote:

...

Dear Committee

We're in danger of actually *removing* an extension from the default set of extensions that is enabled in GHC, which is not what I understood GHC2021 was all about. And it's not because anyone (at least as far as I know) actually thinks that ForeignFunctionInterface is a bad idea and should be deprecated or replaced. What other reasons could there be for turning off an extension that has been on by default for so many years?

ForeignFunctionInterface is part of Haskell2010. Are we saying we disagree with the decision to make it a part of the language standard? I hope not!

Please let's think very hard before doing this!

Cheers Simon

On Mon, 14 Dec 2020 at 22:22, Joachim Breitner wrote:

...

Dear Committe,

three weeks in, we have all votes. So now things are looking more concrete.

As always, the table https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... has the current data.

Would it be helpful to add columns to that table for each committee member? So that you can quickly see who voted what?

The following in are safely in (= need more than one vote to change to get out):

BangPatterns, BinaryLiterals, ConstrainedClassMethods, ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures, MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds, PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType, TypeApplications, TypeSynonymInstances

The following are barely in (exactly 8 votes in favor, and 3 against):

ExistentialQuantification, NamedWildCards, StandaloneKindSignatures, TypeOperators

The following are short one vote (7 in favor, 4 against):

DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, TypeFamilies

I am sure we can have plenty of discussion for each of these. Probably without end. As Simon says, mailing lists don't scale. So I think we have two choices:

1. Let the numbers decide, and accept whatever comes out. According to the process (which we should only follow if we find it helpful) we’d maybe update our votes, and maybe point out new facets, for one week, and then just take whatever has 8 votes.

or

2. Explore a more efficient discussion format.

For the latter I mentioned kialo.com before, and maybe it is worth a try, so I set up a discussion there: https://www.kialo.com/which-haskell-extensions-should-go-into-ghc2021-43548?...

So what do you see there?

There is a discussion tree:

The root is “what goes in GHC2021”

The next layer are all extensions with 7 or 8 votes. (I assume we should focus on those initially, but feel free to add more or ask me to.) For example: TupleSections

And then each of these has a column where we can collect Pros and cons. For example: Pro: Opt-in Syntax Con: Possible clash with extra-comma syntax extensions.

So you can treat it like a wiki, but with structure to organize the discussion.

In fact, each pro and con is itself a node where you can add supporting and disagreeing comments. This means that if you _disagree_ that TupleSections are actually Opt-in syntax, there is a dedicated place to raise that point, rather than putting “Not actually opt-in” in the Con column of TupleSections…

A good way to navigate the discussion seems to be the radial icon in the top left; it opens a radial view of the whole discussion, and you can read arguments by hovering.

The site doesn't offer voting, it is only about structuring the discussion, and it is designed for much larger and much more contentious debates (e.g. “Brexit”). So we’ll see how well it works for us and if it’s helpful.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I’ll happily change my vote to a ‘yes’ - I must’ve missed that it’s already implied while I was going through the list in the user manual. If it’s already on, I don’t see harm in leaving it that way. Thanks, Tom

On 18 Dec 2020, at 08:59, Simon Peyton Jones via ghc-steering-committee wrote:

| In my experience, FFI is the kind of extension that you want to | isolate to a single module, and like Cale (or Iavor with the fancier | type system extensions) I like the indicator at the top of the file | that this module will be dealing with FFI concerns. In that sense, FFI | feels a lot like MagicHash to me, a very important and useful | extension, but one that you don't want (or at least don't *need*) | enabled everywhere. So it's interesting to me that while FFI has | 8 votes now, MagicHash (and UnboxedTuples and UnboxedSums) only has a | single vote.

I have sympathy with this. If it wasn't "in" already I'd say leave it out now. But maybe we should not be so influenced by what it in now?

I'm totally on the fence here.

Simon

| | I don't see excluding FFI from GHC2021 as an argument that it should | be avoided or deprecated, just that it's not a part of the every day | Haskell toolkit. I think it deserves to continue to be part of the | Haskell standard, but is also niche enough to warrant selective | enablement where it's needed. In other words, I think it would be | perfectly fine if the Haskell standard mandated FFI as an extension | that could be enabled on demand (in fact this is how I thought it | worked when I first learned that FFI was included in Haskell2010). | | That all said, there's clearly nothing wrong with enabling it | universally, it's been the default for a while and hasn't caused any | problems I'm aware of. So if Simon M and others feel strongly about | including FFI, I don't want to stand in the way. But I am curious why | we shouldn't include the other parts of the low-level Haskell toolkit | as well. | | Eric | | > On Dec 17, 2020, at 11:47, Cale Gibbard wrote: | > | > My impression of the GHC2021 thing was that it's an arbitrary | > collection of extensions that would make for a sensible default, | > rather than something that was in any way tied to a standardisation | > process. | > | > ForeignFunctionInterface is obviously not going anywhere, but also, | > its use is generally confined to particular modules, where the {-# | > Language ForeignFunctionInterface #-} pragma at the top would be | good | > documentation for what sort of module we're about to see. I was also | > slightly concerned that switching that on may have an impact on | > overall compiler performance, seeing as it may need to interact with | > the driver in more ways than most extensions, but I don't really | know | > and haven't yet done any testing. | > | > I also had no idea it was turned on by default in Haskell2010, | though | > I'm not sure it matters all that much what was turned on in | > Haskell2010 for these purposes either? | > | > That said, I could go either way on this one. | > | > If we're going to turn FFI on, why not throw in all the other | > extensions to FFI? Given that they introduce their own bits of | syntax, | > so could hardly affect anything by accident, I think it would be | > appropriate. | > | > | > | > On Thu, 17 Dec 2020 at 11:40, Simon Marlow | wrote: | >> | >> Dear Committee | >> | >> We're in danger of actually *removing* an extension from the | default set of extensions that is enabled in GHC, which is not what I | understood GHC2021 was all about. And it's not because anyone (at | least as far as I know) actually thinks that ForeignFunctionInterface | is a bad idea and should be deprecated or replaced. What other reasons | could there be for turning off an extension that has been on by | default for so many years? | >> | >> ForeignFunctionInterface is part of Haskell2010. Are we saying we | disagree with the decision to make it a part of the language standard? | I hope not! | >> | >> Please let's think very hard before doing this! | >> | >> Cheers | >> Simon | >> | >> On Mon, 14 Dec 2020 at 22:22, Joachim Breitner wrote: | >>> | >>> Dear Committe, | >>> | >>> three weeks in, we have all votes. So now things are looking more | concrete. | >>> | >>> As always, the table | >>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | >>> thub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposal | >>> s%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.c | >>> | om%7C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011 | >>> | db47%7C1%7C0%7C637438598033649008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC | >>> | 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& | >>> | sdata=NhvlIwuLVahY2XRkBXrPp08jGad5V%2B3dyUxxRfScuVI%3D&reserved= | >>> 0 | >>> has the current data. | >>> | >>> Would it be helpful to add columns to that table for each | committee | >>> member? So that you can quickly see who voted what? | >>> | >>> The following in are safely in (= need more than one vote to | change to get out): | >>> | >>> BangPatterns, BinaryLiterals, ConstrainedClassMethods, | >>> ConstraintKinds, DeriveDataTypeable, DeriveFoldable, | DeriveFunctor, | >>> DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase, | >>> EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, | FlexibleContexts, | >>> FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving, | >>> HexFloatLiterals, ImportQualifiedPost, InstanceSigs, | KindSignatures, | >>> MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, | >>> PolyKinds, PostfixOperators, RankNTypes, StandaloneDeriving, | >>> StarIsType, TypeApplications, TypeSynonymInstances | >>> | >>> The following are barely in (exactly 8 votes in favor, and 3 | against): | >>> | >>> ExistentialQuantification, NamedWildCards, | StandaloneKindSignatures, | >>> TypeOperators | >>> | >>> The following are short one vote (7 in favor, 4 against): | >>> | >>> DerivingStrategies, ForeignFunctionInterface, GADTs, | MonoLocalBinds, | >>> NegativeLiterals, RecordWildCards, ScopedTypeVariables, | >>> TupleSections, TypeFamilies | >>> | >>> | >>> I am sure we can have plenty of discussion for each of these. | >>> Probably without end. As Simon says, mailing lists don't scale. So | I | >>> think we have two choices: | >>> | >>> 1. Let the numbers decide, and accept whatever comes out. | According | >>> to the process (which we should only follow if we find it helpful) | >>> we'd maybe update our votes, and maybe point out new facets, for | one | >>> week, and then just take whatever has 8 votes. | >>> | >>> or | >>> | >>> 2. Explore a more efficient discussion format. | >>> | >>> For the latter I mentioned kialo.com before, and maybe it is worth | a | >>> try, so I set up a discussion there: | >>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww | >>> w.kialo.com%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548% | >>> | 3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com%7C886f71 | >>> | 1c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C | >>> | 0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | >>> | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EBMu9 | >>> n%2BX917NG5L7k7tJMDDnxlclzO0LNAvimEettq4%3D&reserved=0 | >>> | >>> So what do you see there? | >>> | >>> There is a discussion tree: | >>> | >>> The root is "what goes in GHC2021" | >>> | >>> The next layer are all extensions with 7 or 8 votes. | >>> (I assume we should focus on those initially, but feel free to add | >>> more or ask me to.) For example: TupleSections | >>> | >>> And then each of these has a column where we can collect Pros and | cons. | >>> For example: | >>> Pro: Opt-in Syntax | >>> Con: Possible clash with extra-comma syntax extensions. | >>> | >>> So you can treat it like a wiki, but with structure to organize | the | >>> discussion. | >>> | >>> In fact, each pro and con is itself a node where you can add | >>> supporting and disagreeing comments. This means that if you | >>> _disagree_ that TupleSections are actually Opt-in syntax, there is | a | >>> dedicated place to raise that point, rather than putting "Not | >>> actually opt-in" in the Con column of TupleSections... | >>> | >>> A good way to navigate the discussion seems to be the radial icon | in | >>> the top left; it opens a radial view of the whole discussion, and | >>> you can read arguments by hovering. | >>> | >>> | >>> The site doesn't offer voting, it is only about structuring the | >>> discussion, and it is designed for much larger and much more | >>> contentious debates (e.g. "Brexit"). So we'll see how well it | works | >>> for us and if it's helpful. | >>> | >>> Cheers, | >>> Joachim | >>> | >>> | >>> -- | >>> Joachim Breitner | >>> mail@joachim-breitner.de | >>> | >>> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | >>> .joachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7 | >>> | C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47 | >>> | %7C1%7C0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj | >>> | AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat | >>> a=5FRqUoTh1wBOS8Hrj6L5CK9uTtsXCDc2U4zVMKQ2UpY%3D&reserved=0 | >>> | >>> | >>> _______________________________________________ | >>> ghc-steering-committee mailing list | >>> ghc-steering-committee@haskell.org | >>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | >>> il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committ | >>> | ee&data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da | >>> | 08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385980 | >>> | 33659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI | >>> | iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O%2FGAauT8sznxenlzP | >>> 7KMC661xIvVCip588OGEEUj0zI%3D&reserved=0 | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee | >> | &data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da08d | >> | 8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743859803365 | >> | 9005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | >> | TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O%2FGAauT8sznxenlzP7KMC66 | >> 1xIvVCip588OGEEUj0zI%3D&reserved=0 | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&a | > | mp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da08d8a3 | > | 070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637438598033659005 | > | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > | k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O%2FGAauT8sznxenlzP7KMC661xIvVC | > ip588OGEEUj0zI%3D&reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb | 881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385 | 98033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O%2FGAauT8sznxenlzP7 | KMC661xIvVCip588OGEEUj0zI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Fri, Dec 18, 2020, at 08:07, Simon Marlow wrote:

On Fri, 18 Dec 2020 at 03:43, Eric Seidel wrote:

...

In my experience, FFI is the kind of extension that you want to isolate to a single module, and like Cale (or Iavor with the fancier type system extensions) I like the indicator at the top of the file that this module will be dealing with FFI concerns.

I've seen other people express this viewpoint, and I'd like to understand it a bit more. In what way do you see the LANGUAGE pragma at the top of the module as being useful?

To me it's just noise, and unnecessary friction on the developer's workflow. I see LANGUAGE pragmas as useful for experimental or new extensions, when we want to know what code might break if we change it, or we want to add a new extension without breaking old code, or for extensions that we need to be opt-in for a good reason (e.g. TemplateHaskell, which has a significant impact on how we compile things). For long-standing stable extensions, especially ones that are already guarded by syntax, I think LANGUAGE is hurting rather than helping.

I think LANGUAGE pragmas serve two separate purposes, which is the source of the confusion. 1. They can guard new and experimental extensions that aren't ready for inclusion into a standard. This seems to be an uncontroversial use of LANGUAGE. 2. They can also act as a sort of language level in the style of Racket. This is the purpose of extension bundles like Haskell2010 and GHC2021. I think when people say they like the LANGUAGE pragmas at the top of a module, they're referring to use case (2). To be fair, we have very few language extensions currently that act in this way, and FFI is not one of them. But what I think people really want when they make this argument is to have *more* category (2) extensions. So rather than writing {-# LANGUAGE GHC2021 #-} {-# LANGUAGE FFI #-} {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE UnboxedTuples #-} ... we would write {-# LANGUAGE GHC2021 #-} {-# LANGUAGE LowLevelHaskell #-} where LowLevelHaskell implies a coherent set of extensions for dealing with low-level details, and also signifies (much better than the individual extensions) that we should adopt a different mindset when working in this module. Does that make more sense?

...

In that sense, FFI feels a lot like MagicHash to me, a very important and useful extension, but one that you don't want (or at least don't *need*) enabled everywhere. So it's interesting to me that while FFI has 8 votes now, MagicHash (and UnboxedTuples and UnboxedSums) only has a single vote.

To some extent this is historical. Unboxed and unlifted types were always seen as "GHC extensions" to standard Haskell. Another compiler would very likely have a different way of defining primitive operations, and may or may not have explicit unboxed types. With GHC, the goal has always been to provide ways to do what you want without using these extensions, and over time the use of these has become more concentrated in the low-level libraries, as it should be. For those reasons I'm happy for the unboxed/unlifted family of extensions to remain opt-in. The FFI is a different matter: it was designed to be something that any compiler could implement regardless of its choice of low-level primitives and types.

That's an interesting point, but I think that since we're working on GHC2021 rather than Haskell2021, we shouldn't feel uncomfortable including very GHC-specific extensions. Eric

On Thu, Dec 31, 2020, at 06:01, Simon Marlow wrote:

Hi Eric - thanks for the clarification. I'm not against category (2) in general, in fact I think having a LowLevelHaskell category that enables all the unboxed/unlifted-types-related extensions would be a good idea. However, I don't think such a category should include the FFI, because the FFI was designed to be cross-platform, implementation-independent, and to coexist smoothly with the rest of Haskell. I can't see any compelling reason to make it an optional extension.

I'm also not a fan of endorsing the idea of multiple languages. In my view we should be converging on a single language - every extension is destined to either be in a future GHC20xx or to be deprecated.

I don't think category (2) extensions are necessarily incompatible with converging on a single language. We could instead aim for a future where all extensions form a coherent set that *could* be enabled together, and GHC20xx selects a subset that aims to cover 90% of use-cases. Then the expectation might be that modules choose a GHC20xx baseline with zero or more category (2) extensions that enable more advanced features, specifically those that require a change of mindset. For example, - the unboxed type extensions imply that we should be thinking carefully about performance and allocations - TemplateHaskell implies (unfortunately) that the order of declarations is relevant Does FFI imply such a change of mindset? I think that's harder to argue, but something still just feels right about using it as a marker to identify modules that deal with the FFI. I think it's also possible that category (2) extensions are not necessary, but that we've been conditioned to think in terms of using extensions to silo off advanced functionality because we've had to selectively enable them for so long. Joachim, can you change my vote for FFI to "yes"? I think it's already in, but that should make it safely in. Eric

Dear Committee, especially dear Simons, when we originally outlined the process for determining what GHC2021 would be, we aimed for a four week period of discussion, at the end of which we just go with whatever the ballots say. That four week period would end next Tuesday. Now, maybe unsurprisingly, there are many discussions going on, both about concrete extensions and also meta-questions (e.g. should we use GHC2021 to spread certain best practices? Can a certain class of users expect to not have to turn on other extensions? Do we want to preserve the property of some extensions as heralds for a certain kind or style of code?). This poses the question: Should we stick to the process, give everyone a chance to revise their votes, and call it a day on Tuesday? Or would that just lead to foul compromises, and we should keep debating until we have more clarity? In favor of sticking to the process: We expected that something like GHC2021 will cause lots and lots of discussions, many of them related to opinions, and there will likely never be a obvious, clear, definite consensus on what the “best” GHC2021 is. That’s why we set out with a time limit, as picking _some_ GHC2021 (with plenty of obvious extensions safely in) with reasonable effort is better than holding long and very time-consuming discussions with diminishing returns. Also, there will be a later iteration to iron out the wrinkles that we didn’t get to do this round. In favor of continuing the discussion: The discussion is fruitful and interesting. We (well, certainly I) learned a fair bit about the various extensions. Also, discussing the meta-questions and coming to an agreement there could help us produce a more principled, consistent GHC2021, and maybe even help us understand the various purposes and goals of the extensions mechanism beyond GHC2021. And if, I mean when, we finish these discussions, we have likely produced a “better” GHC2021. Personally, I’m leaning towards time-boxing the discussion and concluding the vote on Tuesday. That said, if the committee has energy and motivation to continue debating, I’m certainly up for that (my next two weeks will be relatively quiet, and I might enjoy diving into long discussions – you’ve been warned). I think it would be best if the chars make a judgment call as to how we should proceed. Simon, Simon: How do you want us to proceed? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I'm in favor of keeping to the process -- and for keeping the discussion going. That is, we accept what we have on Tuesday. But we also use this experience to refine our criteria for GHC2021+n, depending on our chosen cadence. In particular, I think the discussion of whether extensions should be used to control language levels is very interesting, and I think we could get somewhere by continuing to work on this front. There is one final step I would advocate for, beyond accepting the extensions we have on Tuesday: we should do a quick check that they form a reasonable set. For example, it would be very strange to allow e.g. TypeFamilies without MonoLocalBinds, or to allow DataKinds but not KindSignatures. I haven't double-checked for whether we meet this standard, but we should. Thanks, Joachim, for steering this ship! Richard

On Dec 19, 2020, at 4:02 PM, Eric Seidel wrote:

One other argument for allowing some more time for discussion: it's the holiday season and people are likely to be busy. I know Arnaud mentioned he would be completely offline for the next couple weeks.

Maybe it would make sense to timebox ourselves to the first or second week of January instead?

...

On Dec 19, 2020, at 14:40, Joachim Breitner wrote:

Dear Committee, especially dear Simons,

when we originally outlined the process for determining what GHC2021 would be, we aimed for a four week period of discussion, at the end of which we just go with whatever the ballots say.

That four week period would end next Tuesday.

Now, maybe unsurprisingly, there are many discussions going on, both about concrete extensions and also meta-questions (e.g. should we use GHC2021 to spread certain best practices? Can a certain class of users expect to not have to turn on other extensions? Do we want to preserve the property of some extensions as heralds for a certain kind or style of code?).

This poses the question: Should we stick to the process, give everyone a chance to revise their votes, and call it a day on Tuesday? Or would that just lead to foul compromises, and we should keep debating until we have more clarity?

In favor of sticking to the process: We expected that something like GHC2021 will cause lots and lots of discussions, many of them related to opinions, and there will likely never be a obvious, clear, definite consensus on what the “best” GHC2021 is. That’s why we set out with a time limit, as picking _some_ GHC2021 (with plenty of obvious extensions safely in) with reasonable effort is better than holding long and very time-consuming discussions with diminishing returns. Also, there will be a later iteration to iron out the wrinkles that we didn’t get to do this round.

In favor of continuing the discussion: The discussion is fruitful and interesting. We (well, certainly I) learned a fair bit about the various extensions. Also, discussing the meta-questions and coming to an agreement there could help us produce a more principled, consistent GHC2021, and maybe even help us understand the various purposes and goals of the extensions mechanism beyond GHC2021. And if, I mean when, we finish these discussions, we have likely produced a “better” GHC2021.

Personally, I’m leaning towards time-boxing the discussion and concluding the vote on Tuesday. That said, if the committee has energy and motivation to continue debating, I’m certainly up for that (my next two weeks will be relatively quiet, and I might enjoy diving into long discussions – you’ve been warned).

I think it would be best if the chars make a judgment call as to how we should proceed. Simon, Simon: How do you want us to proceed?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

My main wondering is whether we will in fact change anybody’s mind. For example, I am happy to accept every extension we are discussing in Kialo, but I am having a hard time writing more reasons why we should really get ScopedTypeVariables in GHC2021. According to the proposal, we would have some community input at this point, right? Maybe it’s a good moment to announce that we have interim results and that people can discuss in the proposal PR. Alejandro El El sáb, 19 dic 2020 a las 23:35, Iavor Diatchki escribió:

To me accepting things on Tuesday feels quite premature. I actually don't even know what we'd be accepting. -Iavor

On Sat, Dec 19, 2020 at 2:08 PM Richard Eisenberg wrote:

...

I'm in favor of keeping to the process -- and for keeping the discussion going. That is, we accept what we have on Tuesday. But we also use this experience to refine our criteria for GHC2021+n, depending on our chosen cadence. In particular, I think the discussion of whether extensions should be used to control language levels is very interesting, and I think we could get somewhere by continuing to work on this front.

There is one final step I would advocate for, beyond accepting the extensions we have on Tuesday: we should do a quick check that they form a reasonable set. For example, it would be very strange to allow e.g. TypeFamilies without MonoLocalBinds, or to allow DataKinds but not KindSignatures. I haven't double-checked for whether we meet this standard, but we should.

Thanks, Joachim, for steering this ship! Richard

...

On Dec 19, 2020, at 4:02 PM, Eric Seidel wrote:

One other argument for allowing some more time for discussion: it's the holiday season and people are likely to be busy. I know Arnaud mentioned he would be completely offline for the next couple weeks.

Maybe it would make sense to timebox ourselves to the first or second week of January instead?

...

On Dec 19, 2020, at 14:40, Joachim Breitner wrote:

Dear Committee, especially dear Simons,

when we originally outlined the process for determining what GHC2021 would be, we aimed for a four week period of discussion, at the end of which we just go with whatever the ballots say.

That four week period would end next Tuesday.

Now, maybe unsurprisingly, there are many discussions going on, both about concrete extensions and also meta-questions (e.g. should we use GHC2021 to spread certain best practices? Can a certain class of users expect to not have to turn on other extensions? Do we want to preserve the property of some extensions as heralds for a certain kind or style of code?).

This poses the question: Should we stick to the process, give everyone a chance to revise their votes, and call it a day on Tuesday? Or would that just lead to foul compromises, and we should keep debating until we have more clarity?

In favor of sticking to the process: We expected that something like GHC2021 will cause lots and lots of discussions, many of them related to opinions, and there will likely never be a obvious, clear, definite consensus on what the “best” GHC2021 is. That’s why we set out with a time limit, as picking _some_ GHC2021 (with plenty of obvious extensions safely in) with reasonable effort is better than holding long and very time-consuming discussions with diminishing returns. Also, there will be a later iteration to iron out the wrinkles that we didn’t get to do this round.

In favor of continuing the discussion: The discussion is fruitful and interesting. We (well, certainly I) learned a fair bit about the various extensions. Also, discussing the meta-questions and coming to an agreement there could help us produce a more principled, consistent GHC2021, and maybe even help us understand the various purposes and goals of the extensions mechanism beyond GHC2021. And if, I mean when, we finish these discussions, we have likely produced a “better” GHC2021.

Personally, I’m leaning towards time-boxing the discussion and concluding the vote on Tuesday. That said, if the committee has energy and motivation to continue debating, I’m certainly up for that (my next two weeks will be relatively quiet, and I might enjoy diving into long discussions – you’ve been warned).

I think it would be best if the chars make a judgment call as to how we should proceed. Simon, Simon: How do you want us to proceed?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

OK, having looked at the table, I'd be fine with defining GHC2020 (or is 2021?) as >= 8. Also, I don't think getting additional input from the community would add any clarity to the process, at least not in ways significantly different from what we've already discussed. Just for fun, my two biggest "disappointments" are: * PolyKinds on by default, because I think that TypeInType is a mistake, but I am ok with it as in practice it rarely matters * RecordWildCards not on by default, because it is a completely opt in feature, which is extremely convenient on occasion, and I find the arguments against it to be roughly equivalent to "I can think of ways to abuse this feature, so you shouldn't use it". What are yours? -Iavor On Sun, Dec 20, 2020 at 7:56 AM Joachim Breitner wrote:

Hi,

Am Sonntag, den 20.12.2020, 08:48 +0100 schrieb Alejandro Serrano Mena:

...

According to the proposal, we would have some community input at this point, right? Maybe it’s a good moment to announce that we have interim results and that people can discuss in the proposal PR.

we _could_ do that, but the process as proposed intentionally limits community input to the hackage statistics and the survey.

We already have long, hard to follow and not in all cases productive discussions among ourselves; would we really expect to get more clarity with more voices?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Samstag, den 19.12.2020, 14:35 -0800 schrieb Iavor Diatchki:

To me accepting things on Tuesday feels quite premature. I actually don't even know what we'd be accepting.

The table https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... is up to date, so all the extensions with a bold number in the “Votes” column (≥ 8). Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi,

Then we should allow a fortnight, say to 18 Jan (my birthday).

if Simon says that his birthday wish from us is a well-thought through, conclusively discussed, shiny and nice GHC2021, then of course we will make it so :-) Am Montag, den 21.12.2020, 19:50 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

As you know, I have found it extremely difficult to make sense of a table with more than 100 rows. I think we need a global summary and I have prepared one here: https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA...

Is it accurate? I have not cross-checked against the vote table in the last week or two. You all have edit permission for this document.

It’s accurate, but checking was was quite tedious, hard to automate, and hence. I guess I can keep it up to date as new votes come in, so that might be fine. Or I scrape the categorization of extensions from the docs ( https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts.html nicely groups them by topic), and generate this view automatically from the data, as part of https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... Would that help?

* Everyone: check that the union of "in" and "barely in" makes sense as a coherent language design * Everyone: make the case for any changes. But only for borderline cases. No point in arguing for something that is nowhere near the borderline, unless you really think everyone has misunderstood

I think the period from now to 4 Jan doesn't count. Then we should allow a fortnight, say to 18 Jan (my birthday).

Is that acceptable?

Very much so, I think, thanks. Also remember to go through your maybes. (If both SPJ and Arnaud turn their “maybe” about UnicodeSyntax to yes it makes it in ;-)) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hello, here is another update to my votes. The change is mostly to eliminate all `maybe` with a concrete `yes` or `no`. Module System ============= ImportQualifiedPost: yes PackageImports: no NoImplicitPrelude: no Notation ======== BlockArguments: yes MultiWayIf: yes LambdaCase: no BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: yes OverloadedStrings: yes OverloadedLists: no OverloadedLabels: no EmptyCase: yes PostfixOperators: yes LexicalNegation: yes UnicodeSyntax: yes NegativeLiterals: no TupleSections: yes ImplicitParams: no ParallelListComp: yes RecursiveDo: yes TransformListComp: no Arrows: no ApplicativeDo: yes QualifiedDo: no MonadComprehensions: no NondecreasingIndentation: no RebindableSyntax: no ExplicitNamespaces: no Data Types ========== DatatypeContexts: no ExistentialQuantification: yes EmptyDataDecls: yes RoleAnnotations: no StrictData: no GADTSyntax: yes GADTs: no Patterns and Guards =================== BangPatterns: yes ViewPatterns: no PatternSynonyms: no NoPatternGuards: no NPlusKPatterns: no Records ======= NamedFieldPuns: yes RecordWildCards: yes DisambiguateRecordFields: no DuplicateRecordFields: no NoTraditionalRecordSyntax: no Deriving ======= DeriveGeneric: yes DeriveLift: yes DeriveDataTypeable: yes EmptyDataDeriving: yes StandaloneDeriving: yes DeriveFunctor: yes DeriveFoldable: yes DeriveTraversable: yes DerivingStrategies: no DerivingVia: no GeneralisedNewtypeDeriving: no DeriveAnyClass: no Class System ============ MultiParamTypeClasses: yes NullaryTypeClasses: yes ConstraintKinds: yes TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes ConstrainedClassMethods: yes DefaultSignatures: no InstanceSigs: yes ExtendedDefaultRules: no FunctionalDependencies: no QuantifiedConstraints: no UndecidableInstances: no IncoherentInstances: no UndecidableSuperClasses: no OverlappingInstances: no Types ===== RankNTypes: yes StandaloneKindSignatures: yes KindSignatures: yes LiberalTypeSynonyms: no ScopedTypeVariables: yes ExplicitForAll: yes AllowAmbiguousTypes: no ImpredicativeTypes: no MonoLocalBinds: no NoMonomorphismRestriction: yes PartialTypeSignatures: no NamedWildCards: no LinearTypes: no TypeApplications: no PolyKinds: no TypeOperators: no StarIsType: yes TypeFamilies: no TypeFamilyDependencies: no DataKinds: no FFI === ForeignFunctionInterface: yes CApiFFI: yes GHCForeignImportPrim: no InterruptibleFFI: no UnliftedFFITypes: no StaticPointers: no Low Level ========= UnboxedSums: no UnboxedTuples: no MagicHash: no UnliftedNewtypes: yes Macros ====== CPP: no TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no Other ===== Unsafe: no Safe: no Trustworthy: no Strict: no Obsolete/Deprecated =================== CUSKs: no TypeInType: no MonadFailDesugaring: yes On Tue, Dec 22, 2020 at 2:06 AM Simon Peyton Jones via ghc-steering-committee wrote:

| It's accurate, but checking was was quite tedious, hard to automate, | and hence. I guess I can keep it up to date as new votes come in, so | that might be fine.

Thanks. The crucial thing is that it's grouped in a logical way, so it's possible to address the question "does this make a coherent language design".

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 21 December 2020 20:26 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: How to proceed? | | Hi, | | > Then we should allow a fortnight, say to 18 Jan (my birthday). | | if Simon says that his birthday wish from us is a well-thought | through, conclusively discussed, shiny and nice GHC2021, then of | course we will make it so :-) | | Am Montag, den 21.12.2020, 19:50 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > As you know, I have found it extremely difficult to make sense of a | table with more than 100 rows. I think we need a global summary and I | have prepared one here: | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs | > | .google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA | > | Na8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com% | > | 7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47% | > | 7C1%7C0%7C637441791891403803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM | > | DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sXj | > Sq8Fwla6AysnF9oW5QObfyRGaNcsSVx%2Bh5046Cqg%3D&reserved=0 | > | > Is it accurate? I have not cross-checked against the vote table in | the last week or two. You all have edit permission for this document. | | It's accurate, but checking was was quite tedious, hard to automate, | and hence. I guess I can keep it up to date as new votes come in, so | that might be fine. | | Or I scrape the categorization of extensions from the docs ( | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc. | gitlab.haskell.org%2Fghc%2Fdoc%2Fusers_guide%2Fexts.html&data=04%7 | C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637441791891413801%7CUnknown%7 | CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV | CI6Mn0%3D%7C1000&sdata=79QzkT3UBoasQjYNBBu9aBy1Q4e1yVPoLOS08cZgnYg | %3D&reserved=0 nicely groups them by topic), and generate this | view automatically from the data, as part of | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0 | b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1UtWLiYPCLx | P4jNf9K9beUXveTRp8SiG6U%2FFSUK3YXo%3D&reserved=0 | | Would that help? | | > * Everyone: check that the union of "in" and "barely in" makes sense | as a | > coherent language design | > * Everyone: make the case for any changes. But only for borderline | cases. No | > point in arguing for something that is nowhere near the | borderline, unless | > you really think everyone has misunderstood | > | > I think the period from now to 4 Jan doesn't count. Then we should | > allow a fortnight, say to 18 Jan (my birthday). | > | > Is that acceptable? | | Very much so, I think, thanks. | | Also remember to go through your maybes. (If both SPJ and Arnaud turn | their "maybe" about UnicodeSyntax to yes it makes it in ;-)) | | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a | 7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YZypxIrkQlmvj0s | MY8tiucfKpZUwQ%2BlUng%2BEKzJsZMA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c | 5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374417 | 91891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RkA6zmdd%2BmBPP9yslk | Mn5yVfWt58hGNjuhAdzel%2Fi6c%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Montag, den 21.12.2020, 21:26 +0100 schrieb Joachim Breitner:

Am Montag, den 21.12.2020, 19:50 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

As you know, I have found it extremely difficult to make sense of a table with more than 100 rows. I think we need a global summary and I have prepared one here: https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA...

Is it accurate? I have not cross-checked against the vote table in the last week or two. You all have edit permission for this document.

It’s accurate, but checking was was quite tedious, hard to automate, and hence. I guess I can keep it up to date as new votes come in, so that might be fine.

Or I scrape the categorization of extensions from the docs ( https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts.html nicely groups them by topic), and generate this view automatically from the data, as part of https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g...

I gave this a shot. My scripts now parse GHC head’s `docs/` folder to understand which topic an extension belongs to, using the same headers that you see on https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts.html

From this I produce the output at https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-g... which tries to mimick Simons manual Google doc.

Parsing this additional data also allowed me to link to the GHC HEAD’s version of the documentation, which means less dead links and in some cases much improved description. Simon, is this sufficient that it can replace manually maintaining the Google doc? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Mittwoch, den 23.12.2020, 10:07 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

Simon, is this sufficient that it can replace manually maintaining the Google doc?

Thank you! Yes, it's 90% as good which is probably enough. Can you put them in a specified order rather than alphabetical? (Having "Class and instance decls" so far from "Types" is odd.)

Tricky. Maybe I can parse docs/users_guide/exts.rst and use the order of that file (putting all those that are _not_ part of that file afterwards). … ok, done. (If the order is now unsuitable I hope that we can improve that at the source, in the GHC docs :-))

TypeApplications has nothing to do with Patterns.

Hmm, this is because GHC’s master users_guide/exts/patterns.rst mentions type_application. This glitch will go away once someone merges https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4673

Why is DeriveGeneric under "Misc" rather than "Deriving"?

Because it’s official place in the documentation at https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/generics.html#extens... is in Docs » 6. Language extensions » 6.19. Miscellaneous » 6.19.3. Generic programming

What is the difference between "Other" and "Misc"?

Miscellaneous is when I find the extension in https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/misc.html Other is when my script can’t make sense of which section it belongs to. This happens when the documentation isn’t grouped under a dedicated header; for example https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ffi.html#extension-F... has Docs » 6. Language extensions » 6.17. Foreign function interface (FFI) I guess in that case I should try to take the title of that section… … done, no Other shows up any more. It would be helpful if GHC would publish a fully machine-readable file with all the meta data about extensions: * Name * Since which version * Category * Link to docs * Implied extensions * Part of Haskell98? Part of Haskell2010? Part of the “default set”? Until we have that, I guess I'll continue scraping the `.rst` files. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, and happy new year to everybody! Even though I share with Arnaud a bit of sadness about GADTs, I think that the set of extensions we ended up with is quite coherent: - We switch on by default some “simple syntactic” extensions, like new forms of numbers, empty cases, and so on. - We put all generically-derivable type classes on the same ground; no more special treatment of Eq, Ord… just because they were there earlier. - We enable the most battle-tested extensions to type classes which never compromise the safety. - We make the kind system more regular by enabling PolyKinds, ConstraintKinds, and KindSignatures; but no fancy promotion from DataKinds. I think it’s good that we’ve decided to keep *both* GADTs and TypeFamilies out. For me this gives the message that type level computation is still something we considered advanced and not fully settled; hence it’s still under a pragma. Kind regards, Alejandro

Hi, as a little Sunday evening statistics and visualization nerding relaxation, I tried to see if I can visualize where the committee members stand on the various kinds of extensions. It seems that “Principal Component Analysis” might be a good fit. In the ~100 dimensional space where each of our ballots inhabits one point, it identifies the primary (and secondary) direction along which we are most diverse (I think). One nice thing is that this produces a two dimensional chart. I was _hoping_ to maybe see “heavy type hackery” and “lots of syntactic sugar” emerge as the two main directions. Well, let’s look at pca.png first… Not quite surprising, we see Tom relatively isolated (Tom voted for 7 extensions that nobody else voted for, and was in general very liberal). Also Iavor is somewhat far off, also not surprising, given his reluctance to go all in on GADTs/TypeFamilies etc. Surprisingly, Richard is quite close to him! Simon PJ and me are very close to each other, and somewhere in the middle, and the others seem to have quite an opposite stand from Iavor in the second principal components? Can we understand these two directions? They are essentially (I believe) eigenvectors in the ~100-dimensional space. I tried to visualize them by another scatter plot, see vectors.png. There, we can see that one’s vote for StarIsType contributes a lot towards the primary principal component, and one for Unicode a lot towards the secondary. We see GADTs and TypeFamilies on the far bottom, and FunDeps not far. This indicates that the y-axis really might be the “heavy type level programming” axis (with type level programming features causing negative numbers). I can’t quite make sense of the x-axis though… I stopped short of coloring the points in this graph by “extension cateogry”… So, no big conclusions to be drawn from this. Also, I am definitely no expert in the Data Sciences, so this may be misguided, or simply wrong. If someone wants to give it a better shot, please do! I am happy to provide the raw data in a simple accessible form. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/