From eric at seidel.io  Tue Dec  1 01:28:21 2020
From: eric at seidel.io (Eric Seidel)
Date: Mon, 30 Nov 2020 20:28:21 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23370=3A_Syntax_for_Modifiers?=
 =?utf-8?q?=2C_Recommendation=3A_Acceptance?=
In-Reply-To: <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
Message-ID: <540d57f1-84c3-490b-a7b4-33d2232b83aa@www.fastmail.com>

I'm still a bit skeptical of the specifics around tying modifiers to types, but I think the proposal is well-motivated and that we should find *some* solution before arrows become too complex.

On Mon, Nov 30, 2020, at 14:52, Richard Eisenberg wrote:
> To my surprise, I found myself leaning against. So I updated and 
> simplified the proposal to remove Modifier. This makes modifiers a bit 
> more magical, but more likely to actually work in practice. The type 
> inference story previously may have been intractable.
> 
> I've requested that the committee consider the updates in parallel with 
> community feedback.
> 
> Thanks,
> Richard
> 
> > On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > 
> > After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
> > 
> > Regards,
> > Alejandro
> > 
> > On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
> >> I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
> >> 
> >> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
> >>> Hi,
> >>> 
> >>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
> >>> Mena:
> >>> > Dear all,
> >>> > This proposal suggests adding syntax for a general notion of
> >>> > modifiers, like the ones we’ve been talking about lately affecting
> >>> > linearity or matchability of arrows. For example, if linear types and
> >>> > unsaturated families are accepted as they stand, we would have `Int
> >>> > #1 -> @U Bool` (or something like that), whereas with this proposal
> >>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
> >>> > 
> >>> > Since the amount of modifiers is likely to increase in the future, I
> >>> > think it’s a great idea to agree and reserve such syntax, instead of
> >>> > coming up with different ways on each proposal. I thus recommend
> >>> > acceptance of this proposal.
> >>> > 
> >>> > The proposal itself:
> >>> > (1) introduces syntax for modifiers in types and defines how to
> >>> > type/kind check them,
> >>> > (2) reserved such syntax for other uses in declarations and terms.
> >>> > 
> >>> > I think the proposal still has its merits only with (1), even though
> >>> > I lean towards accepting both parts of it.
> >>> 
> >>> I like the idea of reserving syntax here, but parts of the proposal
> >>> smell a bit like premature generalization to me. Are we confident that
> >>> all annotations we eventually would like to use with this feature can
> >>> be expressed as types of a kind that is an instance of Modifier? Or
> >>> should we reserve the ability to have annotations that don't fit that
> >>> model?
> >>> 
> >>> Would we ever have annotation that may affect phases earlier than than
> >>> typechecking? What if we want to use (%type e) and (%data e) to help
> >>> with the SingleNamepace issues? Look like useful annotations to me, but
> >>> I am not sure if they fit the framework proposed here.
> >>> 
> >>> The fact that we special-case %1 supports that.
> >>> 
> >>> The proposal explicitly has to state “No modifier polymorphism!”. But
> >>> isn't that indication that using the type system to model the various
> >>> modifiers might be the wrong tool?
> >>> 
> >>> I wonder if there is a way where the %(…) on it’s own only reserve
> >>> syntax, and the various uses of that syntax can be disambiguated
> >>> _statically_ based on the content of …. 
> >>> 
> >>> Not great syntax, because not concise, enough, but morally I’d feel
> >>> more at ease with
> >>> 
> >>>   Int %(multiplicity Many) -> Int
> >>>   Int %(multiplicity 1) -> Int
> >>>   Int %(multiplicity m) -> Int
> >>> 
> >>> where multiplicity is a modifier keyword, to express the existing
> >>> features (including implicit generalization of m). Then we can extend
> >>> this to
> >>> 
> >>>   Int %oneShot -> Int
> >>> 
> >>> and
> >>> 
> >>>   Int %(matchability M) -> Int
> >>> 
> >>> and maybe even
> >>> 
> >>>   foo (%type [a]) -- where foo :: forall a -> ()
> >>> 
> >>> which is a modifier that 
> >>> 
> >>> 
> >>> So at the moment, I am inclined to reject this proposal, until I am
> >>> convinced that we are not painting ourselves into a “all modifiers are
> >>> types of special kinds and that’s all the syntax and behaviour we ever
> >>> need” corner.
> >>> 
> >>> Minor detail: If we can annotate infix use of the (->) “type operator”,
> >>> should we also be able to annotate other infix operators, i.e.
> >>> 
> >>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) 
> >>>   infixexp ::= lexp {modifier} qop infixexp
> >>> 
> >>> 
> >>> 
> >>> Cheers,
> >>> Joachim
> >>> 
> >>> 
> >>> -- 
> >>> Joachim Breitner
> >>>   mail at joachim-breitner.de
> >>>   http://www.joachim-breitner.de/
> >>> 
> >>> 
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>> 
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From simonpj at microsoft.com  Tue Dec  1 08:14:42 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Dec 2020 08:14:42 +0000
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass
In-Reply-To: <CAHnFXOsTLzP_tPkQVbZ33=CPi=Fq9KHdByusc2js51NcbDSJfA@mail.gmail.com>
References: <CAHnFXOsTLzP_tPkQVbZ33=CPi=Fq9KHdByusc2js51NcbDSJfA@mail.gmail.com>
Message-ID: <VI1PR83MB0222E264DBEC1BE7A223940DADF41@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension.

I’m a great fan of Template Haskell, but I didn’t put it in the “on by default” category.

There are lots of “deriving” extensions.  I treated them as a group, but you could perhaps argue that doing so isn’t right. Is there a reason to choose one over the others to be in the on-by-default set?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 30 November 2020 19:42
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass

Dear all,
I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension.

In my case, most of my uses are to derive ToJSON and FromJSON from the Aeson package. I find it very nice to be able to pack all the information about auto-derived instances in a small block, instead of including Eq and Show in the deriving block, and then a few empty instance declarations below. This is definitely mainly a aesthetic reason.

The other reason for adoption is that it makes classes such as Eq or Show less “special”, so one does not have to explain to beginners that some classes can be derived in this way, some others in that other way, and so on. So my other reason for inclusion would be a uniformity one.

Regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/1326dd03/attachment-0001.html>

From mail at joachim-breitner.de  Tue Dec  1 08:25:26 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 Dec 2020 09:25:26 +0100
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass
In-Reply-To: <VI1PR83MB0222E264DBEC1BE7A223940DADF41@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAHnFXOsTLzP_tPkQVbZ33=CPi=Fq9KHdByusc2js51NcbDSJfA@mail.gmail.com>
 <VI1PR83MB0222E264DBEC1BE7A223940DADF41@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <9d05323d98c617c1d3abbb1428952428751b9cb7.camel@joachim-breitner.de>

Am Dienstag, den 01.12.2020, 08:14 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> There are lots of “deriving” extensions.  I treated them as a group,
> but you could perhaps argue that doing so isn’t right. Is there a
> reason to choose one over the others to be in the on-by-default set? 

I think so!

There are extensions like DerivingVia or StandaloneDeriving that come
with new, obvious syntax. These, like many other, have the property
that you can see that they are being used because, well, they are being
used, and requiring the user to write the language extension explicitly
isn’t so useful.

Then there are those that are less visible, but totally harmless and a
natural continuation of what we have, namely more stock deriving
extensions (DerivingFunctor, etc.).


For all those above, even someone who isn't intimately acquainted with
the extensions will not be thrown off when reading it; for the first
group they will see something they don’t know and can read about it.
For the second group… there isn’t even anything to think about, it does
what you think it does.

And then there are those that do “implicit magic”, in particular
DeriveAnyClass. Here, an unsuspecting reader might fully understand
what’s going on.

Worse: With this extension on by default, beginners might try to put
MyCustomClass into their deriving set, and get very unhelpful error
messages:

   Prelude> class Test a where test :: a
   Prelude> data Foo = Foo deriving Test

   <interactive>:4:25: error:
       • Can't make a derived instance of ‘Test Foo’:
           ‘Test’ is not a stock derivable class (Eq, Show, etc.)
           Try enabling DeriveAnyClass
       • In the data declaration for ‘Foo’
   Prelude> :set -XDeriveAnyClass 
   Prelude> data Foo = Foo deriving Test

   <interactive>:6:25: warning: [-Wmissing-methods]
       • No explicit implementation for
           ‘test’
       • In the instance declaration for ‘Test Foo’

   With my (past) educator’s hat on, given that error messages, I say
   “please no!”.

   And with my Haskell author’s head on, I say “Lets get away from
   DeriveAnyClass and move to using deriving via to _explicitly_ say
   what’s going on here”.

   I have absolutely no qualms like this about the other Deriving
   extensions.

   Cheers,
   Joachim


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



From trupill at gmail.com  Tue Dec  1 08:43:57 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 1 Dec 2020 00:43:57 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>

 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 <rae at richarde.dev> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/93c15520/attachment-0001.html>

From trupill at gmail.com  Tue Dec  1 08:45:57 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 1 Dec 2020 00:45:57 -0800
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass
In-Reply-To: <9d05323d98c617c1d3abbb1428952428751b9cb7.camel@joachim-breitner.de>
References: <CAHnFXOsTLzP_tPkQVbZ33=CPi=Fq9KHdByusc2js51NcbDSJfA@mail.gmail.com>
 <VI1PR83MB0222E264DBEC1BE7A223940DADF41@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <9d05323d98c617c1d3abbb1428952428751b9cb7.camel@joachim-breitner.de>
Message-ID: <CAHnFXOt6XvjVxYerF-f+PbxiikNzwURW+XBm4Jqd_7g2DOcKaw@mail.gmail.com>

 Thanks for the illuminating discussion! I’ve been convinced that we should
move away from DeriveAnyClass, and provide and start using ‘via
Generically’ instead. Which happily also gets rid of DefaultSignatures,
which I never liked due to the intimate bundling with the class declaration.

Alejandro

On 1 Dec 2020 at 09:25:26, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Am Dienstag, den 01.12.2020, 08:14 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
>
> There are lots of “deriving” extensions.  I treated them as a group,
>
> but you could perhaps argue that doing so isn’t right. Is there a
>
> reason to choose one over the others to be in the on-by-default set?
>
>
> I think so!
>
> There are extensions like DerivingVia or StandaloneDeriving that come
> with new, obvious syntax. These, like many other, have the property
> that you can see that they are being used because, well, they are being
> used, and requiring the user to write the language extension explicitly
> isn’t so useful.
>
> Then there are those that are less visible, but totally harmless and a
> natural continuation of what we have, namely more stock deriving
> extensions (DerivingFunctor, etc.).
>
>
> For all those above, even someone who isn't intimately acquainted with
> the extensions will not be thrown off when reading it; for the first
> group they will see something they don’t know and can read about it.
> For the second group… there isn’t even anything to think about, it does
> what you think it does.
>
> And then there are those that do “implicit magic”, in particular
> DeriveAnyClass. Here, an unsuspecting reader might fully understand
> what’s going on.
>
> Worse: With this extension on by default, beginners might try to put
> MyCustomClass into their deriving set, and get very unhelpful error
> messages:
>
>   Prelude> class Test a where test :: a
>   Prelude> data Foo = Foo deriving Test
>
>   <interactive>:4:25: error:
>       • Can't make a derived instance of ‘Test Foo’:
>           ‘Test’ is not a stock derivable class (Eq, Show, etc.)
>           Try enabling DeriveAnyClass
>       • In the data declaration for ‘Foo’
>   Prelude> :set -XDeriveAnyClass
>   Prelude> data Foo = Foo deriving Test
>
>   <interactive>:6:25: warning: [-Wmissing-methods]
>       • No explicit implementation for
>           ‘test’
>       • In the instance declaration for ‘Test Foo’
>
>   With my (past) educator’s hat on, given that error messages, I say
>   “please no!”.
>
>   And with my Haskell author’s head on, I say “Lets get away from
>   DeriveAnyClass and move to using deriving via to _explicitly_ say
>   what’s going on here”.
>
>   I have absolutely no qualms like this about the other Deriving
>   extensions.
>
>   Cheers,
>   Joachim
>
>
>   --
>   Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/055bd7d1/attachment.html>

From mail at joachim-breitner.de  Tue Dec  1 08:50:53 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 Dec 2020 09:50:53 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
Message-ID: <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 01.12.2020, 00:43 -0800 schrieb Alejandro Serrano
Mena:
> Thanks everybody for an illuminating discussion about DeriveAnyClass.
> I was not aware of the dark corners of the extension (and actually,
> now I find it weird that GHC itself suggests that extension!). Here
> are my updated votes

Noted!

> apart from a ’No’ to DeriveAnyClass I’ve updated my votes of
> StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’.

JFTR, you also changed OverloadedLists and OverloadedStrings from maybe
to yes.


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



From marlowsd at gmail.com  Tue Dec  1 17:30:57 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 1 Dec 2020 17:30:57 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
Message-ID: <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>

I will also change DeriveAnyClass to no:

## Uncontroversial extensions

I've been writing code with most of these enabled by default for quite
some time now. It saves a lot of LANGUAGE pragmas. Other than
RecordWildCards I doubt any of these are controversial.

BangPatterns: yes
BinaryLiterals: yes
DataKinds: yes
DeriveDataTypeable: yes
DeriveGeneric: yes
EmptyCase: yes
ExistentialQuantification: yes
FlexibleContexts: yes
FlexibleInstances: yes
GADTs: yes
GeneralisedNewtypeDeriving: yes
LambdaCase: yes
MultiParamTypeClasses: yes
MultiWayIf: yes
NoMonomorphismRestriction: yes
OverloadedStrings: yes
PatternSynonyms: yes
RankNTypes: yes
RecordWildCards: yes
ScopedTypeVariables: yes
StandaloneDeriving: yes
TupleSections: yes
TypeFamilies: yes
TypeSynonymInstances: yes
NondecreasingIndentation: yes
ConstrainedClassMethods: yes
ConstraintKinds: yes
DefaultSignatures: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveTraversable: yes
EmptyDataDecls: yes
EmptyDataDeriving: yes
HexFloatLiterals: yes
ImportQualifiedPost: yes
InstanceSigs: yes
KindSignatures: yes
LiberalTypeSynonyms: yes
NamedFieldPuns: yes
  (I don't personally like this, but I can't justify having
  RecordWildcards but not having this)
NegativeLiterals: yes
NumDecimals: yes
PolyKinds: yes
PostfixOperators: yes
UnicodeSyntax: yes
  (but only the language extension, not the UI changes)

## Extensions that are implied by others, or are irrelevant:

GADTSyntax: yes
ExplicitForAll: yes
MonadFailDesugaring: irrelevant
MonoLocalBinds: yes

## Extensions that are deprecated or exist for legacy reasons:

DatatypeContexts: no
NPlusKPatterns: no
CUSKs: no
NoPatternGuards: no
ForeignFunctionInterface: yes
  (already implied by Haskell2010, why do we have this but
  NoPatternGuards?)
NullaryTypeClasses: no
OverlappingInstances: no
IncoherentInstances: no
TypeInType: no

## No to extensions that are too new to include in GHC2021:

QualifiedDo: no
LinearTypes: no
BlockArguments: no
LexicalNegation: no
QuantifiedConstraints: no
StandaloneKindSignatures: no
StarIsType: no

## No to extensions that are opt-in by design:

ApplicativeDo: no
  (can lead to non-deterministic behaviour with non-rule-abiding
  Applicative instances)
PackageImports: no
CPP: no
DeriveLift: no
  (only makes sense with TemplateHaskell, which is opt-in)
TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no
RebindableSyntax: no
Safe: no
Strict: no
StrictData: no
Trustworthy: no
Unsafe: no
ExtendedDefaultRules: no
NoImplicitPrelude: no

## No to unsafe extensions:

UndecidableInstances: no
UndecidableSuperClasses: no

## No to low-level extensions, not intended to be on by default:

UnboxedTuples: no
UnboxedSums: no
MagicHash: no
UnliftedFFITypes: no
UnliftedNewtypes: no
GHCForeignImportPrim: no
InterruptibleFFI: no

## No to record-related extensions

Records are in flux, let's not do any of this in GHC2021.

DisambiguateRecordFields: no
DuplicateRecordFields: no
NoTraditionalRecordSyntax: no
OverloadedLabels: no

## The rest

That leaves some tricky ones, I'm putting all these as "no" or
"maybe"; we could conservatively just say "no" to all of them.

I'm voting NO on these:

Arrows: no
  (not widely used)
ImplicitParams: no
  (not widely used; questionable semantics; functionality available
  with reflection package)
ImpredicativeTypes: no
  (I don't think we want this on by default, right?)
ParallelListComp: no
  (not widely used, most uses are covered by zip)
StaticPointers: no
  (quite a niche extension, only really useful with Distributed Haskell)
TransformListComp: no
  (not widely used)
ViewPatterns: no
  (not widely used, and in my opinion not a good design)
DeriveAnyClass: no
  (see discussion on the mailing list)

I'm undecided on these:

AllowAmbiguousTypes: maybe
TypeApplications: maybe
CApiFFI: maybe
  (harmless, but a bit niche)
DerivingVia: maybe
  (not very widely-used, quite new)
DerivingStrategies: maybe
  (not very widely-used, quite new)
FunctionalDependencies: maybe
  (slightly inclined to "no", given the overlap
  with TypeFamilies and the lack of widespread usage)
ExplicitNamespaces: maybe
  (might change, so defer?)
MonadComprehensions: maybe
  (does this make error messages worse?)
PartialTypeSignatures: maybe
NamedWildCards: maybe
NumericUnderscores: maybe
OverloadedLists: maybe
  (impact on error messages?)
RecursiveDo: maybe
  (but introduced by a keyword so relatively harmless)
RoleAnnotations: maybe
  (not widely used, but when you need it you need it)
TypeFamilyDependencies: maybe
  (not widely used, but when you need it you need it)
TypeOperators: maybe

On Tue, 1 Dec 2020 at 08:51, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 01.12.2020, 00:43 -0800 schrieb Alejandro Serrano
> Mena:
> > Thanks everybody for an illuminating discussion about DeriveAnyClass.
> > I was not aware of the dark corners of the extension (and actually,
> > now I find it weird that GHC itself suggests that extension!). Here
> > are my updated votes
>
> Noted!
>
> > apart from a ’No’ to DeriveAnyClass I’ve updated my votes of
> > StandaloneKindSignatures and ImportQualifiedPost to ‘Yes’.
>
> JFTR, you also changed OverloadedLists and OverloadedStrings from maybe
> to yes.
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/cdb4994a/attachment.html>

From marlowsd at gmail.com  Tue Dec  1 17:35:32 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 1 Dec 2020 17:35:32 +0000
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <dc45dba5-c2e1-45f2-818a-0f8ba837ee7d@www.fastmail.com>
References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>
 <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
 <dc45dba5-c2e1-45f2-818a-0f8ba837ee7d@www.fastmail.com>
Message-ID: <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>

The issue with unsafePerformIO is really just that the proposal says that
it's illegal to use the primops with unsafePerformIO. I don't think it's
possible to make it "illegal" in any meaningful sense, probably a better
way to say it would be "undefined" or "unsupported" or somesuch.

Cheers
Simon

On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:

> This is a very well-written and motivated proposal, and I love that it's
> just three new primops (really two, plus a tag to add some guard rails).
> I'm not very familiar with the literature on delimited continuations, but I
> support going with the most general formulation, especially for primops.
>
> I'm not sure we need to be able to detect all uses of the new primops with
> unsafePerformIO, it's already a deeply unsafe function. Just another thing
> that advanced users will need to keep in mind.
>
> On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
> > Committee,
> >
> > We have been asked to review
> > #313: Delimited continuation primops
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/313
> >
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> >
> > *Summary*
> >
> > The proposal makes no language changes, it only adds three primops
> > <
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification
> >.
> >
> > The main motivation is to support building efficient implementations of
> > Algebraic Effect systems, which depend on being able to efficiently
> > capture a continuation. Currently this is done explicitly, which
> > imposes a severe performance penalty.
> >
> > These primops are the minimal support needed to be able to capture a
> > continuation and apply it at runtime, together with some basic type
> > safety via the PromtTag type to ensure that at least we don't replace a
> > continuation with a computation of a different type.  (there are other
> > ways to go wrong with these primops though, they're not a safe
> > interface by themselves: they need to be wrapped in a safe library).
> >
> > The primops are implemented by copying chunks of stack into the heap.
> > This is something that GHC's runtime already does a lot of, so it's not
> > a new concept, although it does require a new closure type and knock-on
> > changes across several files in the runtime (though it's mainly
> > mechanical). There's a prototype implementation here:
> >
> https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline
> >
> > *Decision*
> > *
> > *
> > I'm going to tentatively recommend acceptance.
> >  * This is a sensible choice for the primtives, being the most general
> > of the alternatives, as explained in the proposal.
> > <
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics
> >
> >  * Would the new primops impose a significant ongoing maintenance
> > burden? Having looked at the patch, although there are some missing
> > pieces, I don't think the new concepts impose any significant new
> > requirements on other parts of the runtime.
> >  * I suspect there may be some difficulties around unsafePerformIO, so
> > I raised that on the github thread
> > <
> https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948
> >
> > Thoughts?
> >
> >
> >
> > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > > Dear Committee,
> > >
> > > this is your secretary speaking:
> > >
> > > Delimited continuation primops
> > > has been proposed by Alexis King
> > > https://github.com/ghc-proposals/ghc-proposals/pull/313
> > >
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> > >
> > > I’ll propose Simon Marlow as the shepherd.
> > >
> > > Please guide us to a conclusion as outlined in
> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > >
> > > Thanks,
> > > Joachim
> > > --
> > > Joachim Breitner
> > >   mail at joachim-breitner.de
> > >   http://www.joachim-breitner.de/
> > >
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/c70653a2/attachment-0001.html>

From mail at joachim-breitner.de  Tue Dec  1 18:21:34 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 Dec 2020 19:21:34 +0100
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>
References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>
 <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
 <dc45dba5-c2e1-45f2-818a-0f8ba837ee7d@www.fastmail.com>
 <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>
Message-ID: <15ceb15c8f9b64ab1ca525d3f2c9068e991cbcf8.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 01.12.2020, 17:35 +0000 schrieb Simon Marlow:
> The issue with unsafePerformIO is really just that the proposal says
> that it's illegal to use the primops with unsafePerformIO. I don't
> think it's possible to make it "illegal" in any meaningful sense,
> probably a better way to say it would be "undefined" or "unsupported"
> or somesuch.

what is the impact of this? Naive question (I should probably study the
proposal more):

Is it the case that delimited continuations will be deeply buried in
some libraries; unsafePerformIO is deeply buried in some other library?
If so, is there even a chance to make these libraries safe, so that the
undefined behavior doesn’t hit?

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



From eric at seidel.io  Tue Dec  1 18:25:04 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 01 Dec 2020 13:25:04 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23313=3A_Delimi?=
 =?utf-8?q?ted_continuation_primops=2C_Shepherd=3A_Simon_Marlow?=
In-Reply-To: <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>
References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>
 <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
 <dc45dba5-c2e1-45f2-818a-0f8ba837ee7d@www.fastmail.com>
 <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>
Message-ID: <d84a535e-3e47-4351-a463-1cacf6311045@www.fastmail.com>

Oh I see. I'm always uncomfortable declaring things "undefined" because of how C/C++ compilers can run wild  with code that invokes UB. So I kinda prefer saying that it's "illegal but unchecked".

On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote:
> The issue with unsafePerformIO is really just that the proposal says 
> that it's illegal to use the primops with unsafePerformIO. I don't 
> think it's possible to make it "illegal" in any meaningful sense, 
> probably a better way to say it would be "undefined" or "unsupported" 
> or somesuch.
> 
> Cheers
> Simon
> 
> On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:
> > This is a very well-written and motivated proposal, and I love that it's just three new primops (really two, plus a tag to add some guard rails). I'm not very familiar with the literature on delimited continuations, but I support going with the most general formulation, especially for primops.
> > 
> > I'm not sure we need to be able to detect all uses of the new primops with unsafePerformIO, it's already a deeply unsafe function. Just another thing that advanced users will need to keep in mind.
> > 
> > On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
> > > Committee,
> > > 
> > > We have been asked to review 
> > > #313: Delimited continuation primops
> > > 
> > > https://github.com/ghc-proposals/ghc-proposals/pull/313
> > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> > > 
> > > *Summary*
> > > 
> > > The proposal makes no language changes, it only adds three primops 
> > > <https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification>.
> > > 
> > > The main motivation is to support building efficient implementations of 
> > > Algebraic Effect systems, which depend on being able to efficiently 
> > > capture a continuation. Currently this is done explicitly, which 
> > > imposes a severe performance penalty.
> > > 
> > > These primops are the minimal support needed to be able to capture a 
> > > continuation and apply it at runtime, together with some basic type 
> > > safety via the PromtTag type to ensure that at least we don't replace a 
> > > continuation with a computation of a different type.  (there are other 
> > > ways to go wrong with these primops though, they're not a safe 
> > > interface by themselves: they need to be wrapped in a safe library).
> > > 
> > > The primops are implemented by copying chunks of stack into the heap. 
> > > This is something that GHC's runtime already does a lot of, so it's not 
> > > a new concept, although it does require a new closure type and knock-on 
> > > changes across several files in the runtime (though it's mainly 
> > > mechanical). There's a prototype implementation here: 
> > > https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline
> > > 
> > > *Decision*
> > > *
> > > *
> > > I'm going to tentatively recommend acceptance. 
> > >  * This is a sensible choice for the primtives, being the most general 
> > > of the alternatives, as explained in the proposal. 
> > > <https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics>
> > >  * Would the new primops impose a significant ongoing maintenance 
> > > burden? Having looked at the patch, although there are some missing 
> > > pieces, I don't think the new concepts impose any significant new 
> > > requirements on other parts of the runtime.
> > >  * I suspect there may be some difficulties around unsafePerformIO, so 
> > > I raised that on the github thread 
> > > <https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948>
> > > Thoughts?
> > > 
> > > 
> > > 
> > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > Dear Committee,
> > > > 
> > > > this is your secretary speaking:
> > > > 
> > > > Delimited continuation primops
> > > > has been proposed by Alexis King
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
> > > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> > > > 
> > > > I’ll propose Simon Marlow as the shepherd.
> > > > 
> > > > Please guide us to a conclusion as outlined in 
> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > 
> > > > Thanks,
> > > > Joachim
> > > > -- 
> > > > Joachim Breitner
> > > >   mail at joachim-breitner.de
> > > >   http://www.joachim-breitner.de/
> > > > 
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From rae at richarde.dev  Tue Dec  1 18:27:53 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 1 Dec 2020 18:27:53 +0000
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
Message-ID: <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>

This thread has seen only positive responses, and with no responses for the past 6 days. I'm thus inclined to accept the proposal.

However, there are open questions around the following points:
* the concrete syntax (pending discussion on #370)
* defaulting rules (as raised by Alejandro in this thread)

Conveniently, these are both listed as Unresolved Questions in the proposal itself. We need a way of resolving these questions. The syntax question may become clearer once we know what to do about #370. The defaulting question is harder. I vote to return to this question once #378 has settled somewhat -- but even then, it will be hard. Still, I think we should move forward with accepting the main proposal, and we can continue to debate the defaulting strategy in a further thread, perhaps in parallel with reviewing the (already existing) implementation.

I will accept this proposal as written at the end of the week, barring commentary here (or on GitHub) to stop me.

Thanks!
Richard

> On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I'm on board with unsaturated type families.
> 
> Like Linear Haskell, it's quite a "big" proposal, but accepting it is compatible with idea of Haskell as a laboratory for exploration.  I think we should flag it as experimental, with the implication that details are liable to change as we gain experience.
> 
> Like others, I'd like us to converge on #370 before fixing syntax.
> 
> I don’t have a strong opinion about the defaulting stuff.
> 
> Declaration of interest: I'm a co-author on the paper.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 20 November 2020 19:36
> |  To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-
> |  committee at haskell.org>
> |  Subject: [ghc-steering-committee] Unsaturated type families (#242)
> |  
> |  Hi committee,
> |  
> |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
> |  
> |  Proposal:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
> |  families%2Fproposals%2F0000-unsaturated-type-
> |  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e
> |  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374
> |  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> |  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9ZXOjmE
> |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
> |  ICFP'19 paper:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> |  microsoft.com%2Fen-
> |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-type-
> |  families-icfp-
> |  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e4038
> |  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741497
> |  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fPAr498F
> |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
> |  Discussion:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd
> |  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9N0y7l
> |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
> |  
> |  The central idea is to allow type functions (both type families and
> |  type synonyms) to appear unsaturated. (Currently, all type functions
> |  are required syntactically to be applied to all parameters they are
> |  declared with.) This poses a problem for type inference, as detailed
> |  in both the proposal and the paper. The key question: if we have (f a
> |  ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g
> |  is a type function. This proposal thus describes a mechanism to
> |  introduce a new flavor of arrow, such that we can identify type
> |  functions by their kind. Specifically, we have regular types like
> |  Maybe :: Type -> @M Type (where the M stands for "matchable"), but
> |  type functions like F :: Type -> @U Type (where the U stands for
> |  "unmatchable"). Unmatchable applications can not be decomposed during
> |  type inference.
> |  
> |  Much of the proposal is concerned with backward-compatibility: most
> |  users will not want to write @M or @U after each of their arrows, so
> |  the proposal describes ways of defaulting this behavior to match
> |  (most) programmers' expectations.
> |  
> |  The proposal also includes matchability polymorphism, the ability to
> |  abstract over a matchability parameter.
> |  
> |  Pros:
> |  + This proposal greatly increases the expressiveness of Haskell's type
> |  system.
> |  + With this proposal, we can finally do proper functional programming
> |  in types, rather than just in terms.
> |  + This proposal is a key ingredient toward having dependent types, as
> |  + unsaturated functions are commonplace in terms, and thus should also
> |  be supported in types. (Allowing unsaturated functions in types was a
> |  key difference between Adam Gundry's proposal for dependent types
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadam
> |  .gundry.co.uk%2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40microsoft
> |  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011
> |  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> |  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> |  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=0,
> |  which requires a notion of a subset of the type and term languages
> |  shared in common, and mine, which makes no distinction between terms
> |  and types.) There is a prototype implementation.
> |  + The ideas are backed up by peer-reviewed research.
> |  + Despite focusing on type families, this work applies equally to
> |  ordinary functions which might be used in types once we have stronger
> |  support for dependent types.
> |  
> |  Cons:
> |  - This adds a new dimension of complexity to our kind system, by
> |  separating out matchable and unmatchable arrows.
> |  - The rules for defaulting appear convenient in practice, but are
> |  somewhat arbitrary.
> |  - The rules for defaulting care about context -- does an arrow appear
> |  in the type of a term or the type of a type? These rules thus go
> |  against the spirit of #378, which advocates for not accepting features
> |  that distinguish between types and terms.
> |  
> |  Recommendation: With reservations, I recommend acceptance. I think
> |  that the power to use higher-order programming should not be
> |  restricted to terms, and allowing unsaturated functions at compile
> |  time is necessary in order to have convenient dependent types.
> |  However, I am concerned about the extra complexity of matchability. A
> |  key open question for me is how much matchability is apparent to users
> |  -- even ones using some higher-order type-level programming. If
> |  matchability is pervasive, then I would lean against. But my
> |  expectation is that matchability fades into the background -- much
> |  like levity polymorphism (unless you want it).
> |  
> |  Open question: What to do about syntax? The proposed syntax is
> |  sensible. However, #370 suggests an alternative syntax that might be
> |  more forward-thinking.
> |  
> |  Richard
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e403
> |  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374149
> |  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0%2BOib
> |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0


From arnaud.spiwack at tweag.io  Wed Dec  2 08:43:01 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 2 Dec 2020 09:43:01 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
Message-ID: <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>

Here is my updated vote:

## I don't know what these are

LexicalNegation: maybe
NondecreasingIndentation: maybe

## No opinion yet

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

BlockArguments: maybe
CUSKs: maybe
DataKinds: maybe
DefaultSignatures: maybe
DisambiguateRecordFields: maybe
DuplicateRecordFields: maybe
ImportQualifiedPost: maybe
MonadComprehensions: maybe
   ^ It's fairly popular this one, but I don't know the effects on
   type inference. I feel it may be a similar case as the OverloadedX
   extensions, in which case it feels premature to add it to GHC2021.
NamedFieldPuns: maybe
   ^ While I live and breath for NamedFieldPuns, it does remove some
   shadowing warnings, so it does make some things harder, and it's
   likely that we want this one left out of this round.
NamedWildCards: maybe
RecordWildCards: maybe
NullaryTypeClasses: maybe
NumDecimals: maybe
PackageImports: maybe
ParallelListComp: maybe
PolyKinds: maybe
RankNTypes: maybe
RecursiveDo: maybe
TransformListComp: maybe
TypeInType: maybe
TypeSynonymInstances: maybe
UnliftedFFITypes: maybe
ScopedTypeVariables: maybe
    ^ There seem to be discussion about the type-signature-in-pattern
    part of this extension, which I have no opinion about. I'm very
    much in favour of the bind-type-signature-variable parts. But I
    guess this is likely to be too controversial an extension for this
    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
ForeignFunctionInterface: no
GHCForeignImportPrim: no
InterruptibleFFI: no
MagicHash: no
UnboxedSums: no
UnboxedTuples: no
    ^ Though, frankly, all of MagicHash, UnboxedSums, and
    UnboxedTuples could very well become not-advanced in a
    not-so-far-future. Then we could turn them on by default as
    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

## Uncommon extensions

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

## Deprecated extensions

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

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

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

From tomjharding at live.co.uk  Wed Dec  2 10:18:01 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Wed, 2 Dec 2020 10:18:01 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
Message-ID: <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/54f03773/attachment.html>

From marlowsd at gmail.com  Wed Dec  2 13:33:58 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 2 Dec 2020 13:33:58 +0000
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <d84a535e-3e47-4351-a463-1cacf6311045@www.fastmail.com>
References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>
 <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
 <dc45dba5-c2e1-45f2-818a-0f8ba837ee7d@www.fastmail.com>
 <CANsrgPK2nmdz1-tagdrpcbr4v3B46v1mEtG7qO2SuWnCYXJjgg@mail.gmail.com>
 <d84a535e-3e47-4351-a463-1cacf6311045@www.fastmail.com>
Message-ID: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>

"Illegal but unchecked" would be fine too, although we do already use the
term "undefined" in the documentation for various primops.

We've so far taken the approach that undefined behaviour in primops is OK.
The idea is that libraries built on top can provide a safe and
fully-defined API. e.g.

* division-by-zero is undefined (libraries are supposed to check before
invoking the primop)
* The uncheckedIShift family are undefined for arguments outside the
allowed bounds
* unsafeCoerce is undefined when used in certain ways, of course

There are probably more that aren't documented.

Cheers
Siimon


On Tue, 1 Dec 2020 at 18:25, Eric Seidel <eric at seidel.io> wrote:

> Oh I see. I'm always uncomfortable declaring things "undefined" because of
> how C/C++ compilers can run wild  with code that invokes UB. So I kinda
> prefer saying that it's "illegal but unchecked".
>
> On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote:
> > The issue with unsafePerformIO is really just that the proposal says
> > that it's illegal to use the primops with unsafePerformIO. I don't
> > think it's possible to make it "illegal" in any meaningful sense,
> > probably a better way to say it would be "undefined" or "unsupported"
> > or somesuch.
> >
> > Cheers
> > Simon
> >
> > On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:
> > > This is a very well-written and motivated proposal, and I love that
> it's just three new primops (really two, plus a tag to add some guard
> rails). I'm not very familiar with the literature on delimited
> continuations, but I support going with the most general formulation,
> especially for primops.
> > >
> > > I'm not sure we need to be able to detect all uses of the new primops
> with unsafePerformIO, it's already a deeply unsafe function. Just another
> thing that advanced users will need to keep in mind.
> > >
> > > On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
> > > > Committee,
> > > >
> > > > We have been asked to review
> > > > #313: Delimited continuation primops
> > > >
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
> > > >
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> > > >
> > > > *Summary*
> > > >
> > > > The proposal makes no language changes, it only adds three primops
> > > > <
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification
> >.
> > > >
> > > > The main motivation is to support building efficient implementations
> of
> > > > Algebraic Effect systems, which depend on being able to efficiently
> > > > capture a continuation. Currently this is done explicitly, which
> > > > imposes a severe performance penalty.
> > > >
> > > > These primops are the minimal support needed to be able to capture a
> > > > continuation and apply it at runtime, together with some basic type
> > > > safety via the PromtTag type to ensure that at least we don't
> replace a
> > > > continuation with a computation of a different type.  (there are
> other
> > > > ways to go wrong with these primops though, they're not a safe
> > > > interface by themselves: they need to be wrapped in a safe library).
> > > >
> > > > The primops are implemented by copying chunks of stack into the
> heap.
> > > > This is something that GHC's runtime already does a lot of, so it's
> not
> > > > a new concept, although it does require a new closure type and
> knock-on
> > > > changes across several files in the runtime (though it's mainly
> > > > mechanical). There's a prototype implementation here:
> > > >
> https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline
> > > >
> > > > *Decision*
> > > > *
> > > > *
> > > > I'm going to tentatively recommend acceptance.
> > > >  * This is a sensible choice for the primtives, being the most
> general
> > > > of the alternatives, as explained in the proposal.
> > > > <
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics
> >
> > > >  * Would the new primops impose a significant ongoing maintenance
> > > > burden? Having looked at the patch, although there are some missing
> > > > pieces, I don't think the new concepts impose any significant new
> > > > requirements on other parts of the runtime.
> > > >  * I suspect there may be some difficulties around unsafePerformIO,
> so
> > > > I raised that on the github thread
> > > > <
> https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948
> >
> > > > Thoughts?
> > > >
> > > >
> > > >
> > > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > > > Dear Committee,
> > > > >
> > > > > this is your secretary speaking:
> > > > >
> > > > > Delimited continuation primops
> > > > > has been proposed by Alexis King
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
> > > > >
> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
> > > > >
> > > > > I’ll propose Simon Marlow as the shepherd.
> > > > >
> > > > > Please guide us to a conclusion as outlined in
> > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > >
> > > > > Thanks,
> > > > > Joachim
> > > > > --
> > > > > Joachim Breitner
> > > > >   mail at joachim-breitner.de
> > > > >   http://www.joachim-breitner.de/
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/10f80633/attachment.html>

From eric at seidel.io  Wed Dec  2 14:21:51 2020
From: eric at seidel.io (Eric Seidel)
Date: Wed, 2 Dec 2020 09:21:51 -0500
Subject: [ghc-steering-committee] Please review #313: Delimited
	continuation primops, Shepherd: Simon Marlow
In-Reply-To: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
References: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
Message-ID: <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>

I think the key distinction between “undefined” as used in C/C++ and what I call “illegal but unchecked” is that the optimizer operates under the assumption that “undefined” behavior is impossible. This is what leads to the bizarre and scary stories that people post about UB, but it also lets C/C++ compilers emit much more efficient code in some common places. In contrast, an “illegal but unchecked” operation would be left alone by the optimizer. The runtime behavior would be unspecified and possibly platform-dependent, but still more constrained and predictable than UB. 

I agree that unsafe primops are fine, but I’m curious now if GHC optimizes based on the assumption that they’re used correctly. 

Sent from my iPhone

> On Dec 2, 2020, at 08:34, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> 
> "Illegal but unchecked" would be fine too, although we do already use the term "undefined" in the documentation for various primops.
> 
> We've so far taken the approach that undefined behaviour in primops is OK. The idea is that libraries built on top can provide a safe and fully-defined API. e.g.
> 
> * division-by-zero is undefined (libraries are supposed to check before invoking the primop)
> * The uncheckedIShift family are undefined for arguments outside the allowed bounds
> * unsafeCoerce is undefined when used in certain ways, of course
> 
> There are probably more that aren't documented.
> 
> Cheers
> Siimon
> 
> 
>> On Tue, 1 Dec 2020 at 18:25, Eric Seidel <eric at seidel.io> wrote:
>> Oh I see. I'm always uncomfortable declaring things "undefined" because of how C/C++ compilers can run wild  with code that invokes UB. So I kinda prefer saying that it's "illegal but unchecked".
>> 
>> On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote:
>> > The issue with unsafePerformIO is really just that the proposal says 
>> > that it's illegal to use the primops with unsafePerformIO. I don't 
>> > think it's possible to make it "illegal" in any meaningful sense, 
>> > probably a better way to say it would be "undefined" or "unsupported" 
>> > or somesuch.
>> > 
>> > Cheers
>> > Simon
>> > 
>> > On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:
>> > > This is a very well-written and motivated proposal, and I love that it's just three new primops (really two, plus a tag to add some guard rails). I'm not very familiar with the literature on delimited continuations, but I support going with the most general formulation, especially for primops.
>> > > 
>> > > I'm not sure we need to be able to detect all uses of the new primops with unsafePerformIO, it's already a deeply unsafe function. Just another thing that advanced users will need to keep in mind.
>> > > 
>> > > On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
>> > > > Committee,
>> > > > 
>> > > > We have been asked to review 
>> > > > #313: Delimited continuation primops
>> > > > 
>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
>> > > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
>> > > > 
>> > > > *Summary*
>> > > > 
>> > > > The proposal makes no language changes, it only adds three primops 
>> > > > <https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification>.
>> > > > 
>> > > > The main motivation is to support building efficient implementations of 
>> > > > Algebraic Effect systems, which depend on being able to efficiently 
>> > > > capture a continuation. Currently this is done explicitly, which 
>> > > > imposes a severe performance penalty.
>> > > > 
>> > > > These primops are the minimal support needed to be able to capture a 
>> > > > continuation and apply it at runtime, together with some basic type 
>> > > > safety via the PromtTag type to ensure that at least we don't replace a 
>> > > > continuation with a computation of a different type.  (there are other 
>> > > > ways to go wrong with these primops though, they're not a safe 
>> > > > interface by themselves: they need to be wrapped in a safe library).
>> > > > 
>> > > > The primops are implemented by copying chunks of stack into the heap. 
>> > > > This is something that GHC's runtime already does a lot of, so it's not 
>> > > > a new concept, although it does require a new closure type and knock-on 
>> > > > changes across several files in the runtime (though it's mainly 
>> > > > mechanical). There's a prototype implementation here: 
>> > > > https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline
>> > > > 
>> > > > *Decision*
>> > > > *
>> > > > *
>> > > > I'm going to tentatively recommend acceptance. 
>> > > >  * This is a sensible choice for the primtives, being the most general 
>> > > > of the alternatives, as explained in the proposal. 
>> > > > <https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics>
>> > > >  * Would the new primops impose a significant ongoing maintenance 
>> > > > burden? Having looked at the patch, although there are some missing 
>> > > > pieces, I don't think the new concepts impose any significant new 
>> > > > requirements on other parts of the runtime.
>> > > >  * I suspect there may be some difficulties around unsafePerformIO, so 
>> > > > I raised that on the github thread 
>> > > > <https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948>
>> > > > Thoughts?
>> > > > 
>> > > > 
>> > > > 
>> > > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> > > > > Dear Committee,
>> > > > > 
>> > > > > this is your secretary speaking:
>> > > > > 
>> > > > > Delimited continuation primops
>> > > > > has been proposed by Alexis King
>> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
>> > > > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
>> > > > > 
>> > > > > I’ll propose Simon Marlow as the shepherd.
>> > > > > 
>> > > > > Please guide us to a conclusion as outlined in 
>> > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> > > > > 
>> > > > > Thanks,
>> > > > > Joachim
>> > > > > -- 
>> > > > > Joachim Breitner
>> > > > >   mail at joachim-breitner.de
>> > > > >   http://www.joachim-breitner.de/
>> > > > > 
>> > > > > 
>> > > > > _______________________________________________
>> > > > > ghc-steering-committee mailing list
>> > > > > ghc-steering-committee at haskell.org
>> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > > > _______________________________________________
>> > > > ghc-steering-committee mailing list
>> > > > ghc-steering-committee at haskell.org
>> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > > >
>> > > _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/60cbc315/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Dec  2 15:30:37 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 2 Dec 2020 16:30:37 +0100
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>

Dear all,

I'm a bit worried by the limited response from the committee on this
proposal. It is a non-trivial proposal, and I think it deserves more eyes.
So please have a look at them so that we can commit to this with confidence.

/Arnaud

On Tue, Dec 1, 2020 at 7:28 PM Richard Eisenberg <rae at richarde.dev> wrote:

> This thread has seen only positive responses, and with no responses for
> the past 6 days. I'm thus inclined to accept the proposal.
>
> However, there are open questions around the following points:
> * the concrete syntax (pending discussion on #370)
> * defaulting rules (as raised by Alejandro in this thread)
>
> Conveniently, these are both listed as Unresolved Questions in the
> proposal itself. We need a way of resolving these questions. The syntax
> question may become clearer once we know what to do about #370. The
> defaulting question is harder. I vote to return to this question once #378
> has settled somewhat -- but even then, it will be hard. Still, I think we
> should move forward with accepting the main proposal, and we can continue
> to debate the defaulting strategy in a further thread, perhaps in parallel
> with reviewing the (already existing) implementation.
>
> I will accept this proposal as written at the end of the week, barring
> commentary here (or on GitHub) to stop me.
>
> Thanks!
> Richard
>
> > On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
> >
> > I'm on board with unsaturated type families.
> >
> > Like Linear Haskell, it's quite a "big" proposal, but accepting it is
> compatible with idea of Haskell as a laboratory for exploration.  I think
> we should flag it as experimental, with the implication that details are
> liable to change as we gain experience.
> >
> > Like others, I'd like us to converge on #370 before fixing syntax.
> >
> > I don’t have a strong opinion about the defaulting stuff.
> >
> > Declaration of interest: I'm a co-author on the paper.
> >
> > Simon
> >
> > |  -----Original Message-----
> > |  From: ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> > |  Sent: 20 November 2020 19:36
> > |  To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-
> > |  committee at haskell.org>
> > |  Subject: [ghc-steering-committee] Unsaturated type families (#242)
> > |
> > |  Hi committee,
> > |
> > |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
> > |
> > |  Proposal:
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > |  ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
> > |  families%2Fproposals%2F0000-unsaturated-type-
> > |  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7Cbd9e62e3137e
> > |  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374
> > |  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > |  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9ZXOjmE
> > |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
> > |  ICFP'19 paper:
> > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .
> > |  microsoft.com%2Fen-
> > |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-type-
> > |  families-icfp-
> > |  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7Cbd9e62e3137e4038
> > |  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741497
> > |  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fPAr498F
> > |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
> > |  Discussion:
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > |  ub.com%2Fghc-proposals%2Fghc-
> > |  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7Cbd
> > |  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> > |  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9N0y7l
> > |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
> > |
> > |  The central idea is to allow type functions (both type families and
> > |  type synonyms) to appear unsaturated. (Currently, all type functions
> > |  are required syntactically to be applied to all parameters they are
> > |  declared with.) This poses a problem for type inference, as detailed
> > |  in both the proposal and the paper. The key question: if we have (f a
> > |  ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g
> > |  is a type function. This proposal thus describes a mechanism to
> > |  introduce a new flavor of arrow, such that we can identify type
> > |  functions by their kind. Specifically, we have regular types like
> > |  Maybe :: Type -> @M Type (where the M stands for "matchable"), but
> > |  type functions like F :: Type -> @U Type (where the U stands for
> > |  "unmatchable"). Unmatchable applications can not be decomposed during
> > |  type inference.
> > |
> > |  Much of the proposal is concerned with backward-compatibility: most
> > |  users will not want to write @M or @U after each of their arrows, so
> > |  the proposal describes ways of defaulting this behavior to match
> > |  (most) programmers' expectations.
> > |
> > |  The proposal also includes matchability polymorphism, the ability to
> > |  abstract over a matchability parameter.
> > |
> > |  Pros:
> > |  + This proposal greatly increases the expressiveness of Haskell's type
> > |  system.
> > |  + With this proposal, we can finally do proper functional programming
> > |  in types, rather than just in terms.
> > |  + This proposal is a key ingredient toward having dependent types, as
> > |  + unsaturated functions are commonplace in terms, and thus should also
> > |  be supported in types. (Allowing unsaturated functions in types was a
> > |  key difference between Adam Gundry's proposal for dependent types
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadam
> > |  .gundry.co.uk
> %2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40microsoft
> > |  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011
> > |  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > |  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> > |  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=0,
> > |  which requires a notion of a subset of the type and term languages
> > |  shared in common, and mine, which makes no distinction between terms
> > |  and types.) There is a prototype implementation.
> > |  + The ideas are backed up by peer-reviewed research.
> > |  + Despite focusing on type families, this work applies equally to
> > |  ordinary functions which might be used in types once we have stronger
> > |  support for dependent types.
> > |
> > |  Cons:
> > |  - This adds a new dimension of complexity to our kind system, by
> > |  separating out matchable and unmatchable arrows.
> > |  - The rules for defaulting appear convenient in practice, but are
> > |  somewhat arbitrary.
> > |  - The rules for defaulting care about context -- does an arrow appear
> > |  in the type of a term or the type of a type? These rules thus go
> > |  against the spirit of #378, which advocates for not accepting features
> > |  that distinguish between types and terms.
> > |
> > |  Recommendation: With reservations, I recommend acceptance. I think
> > |  that the power to use higher-order programming should not be
> > |  restricted to terms, and allowing unsaturated functions at compile
> > |  time is necessary in order to have convenient dependent types.
> > |  However, I am concerned about the extra complexity of matchability. A
> > |  key open question for me is how much matchability is apparent to users
> > |  -- even ones using some higher-order type-level programming. If
> > |  matchability is pervasive, then I would lean against. But my
> > |  expectation is that matchability fades into the background -- much
> > |  like levity polymorphism (unless you want it).
> > |
> > |  Open question: What to do about syntax? The proposed syntax is
> > |  sensible. However, #370 suggests an alternative syntax that might be
> > |  more forward-thinking.
> > |
> > |  Richard
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7Cbd9e62e3137e403
> > |  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374149
> > |  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0%2BOib
> > |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/2b2036ff/attachment.html>

From tomjharding at live.co.uk  Wed Dec  2 16:41:22 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Wed, 2 Dec 2020 16:41:22 +0000
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
 <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
Message-ID: <3E6AAF1E-7E3F-4740-966E-52B3C0DD17B9@live.co.uk>

I felt rather too biased to comment on this proposal, as I have been very publicly vocal about how excited I am to see it in GHC. However, it occurs to me that my thoughts on the proposal are rather too scattered across the Internet, so I’ll try to collate the main points that I have. I will caveat these by saying that they have mostly been addressed in the thread and/or the proposal, and they certainly don’t change my opinion that the proposal be accepted.

* A pretty significant consequence of this proposal is partial application of type synonyms. I think the inability to partially apply these is a rather counter-intuitive restriction to beginners (particularly when they’ve just started to get familiar with partial application at the value level). Certainly, when introducing colleagues to Haskell, it is a question that comes up reasonably often: “why must I write type T = Maybe and never type T x = Maybe x?” Of course, once one considers the importance of `f a ~ g b <=> (f ~ g, a ~ b)` for inference, and an example like type T x = Either x Int, this starts to make more sense, but we’ve had to reach a surprisingly deep level of understanding to figure this out.

Naturally, lifting that restriction is going to mean one less thing to explain ("type-level works like term-level!”) but I worry about the potential error messages here. If a user is at a point where they feel comfortable playing with type families, I think they’re perhaps more primed for strange error messages, but can I ever run into a matchability mismatch error as an absolute beginner? The classic example (that Joachim already raised) is trying to write a functor instance for type Id x = x. If I’m new to the language, it’s potentially not clear to me why I can’t do this (at least until the rest of Csongor’s research finds its way into the compiler). In which case, I’d like to see a more specialised error such as, “You can’t write a class instance for a partially-applied type synonym”, rather than exposing someone to 'M and 'U in their first week of Haskell.

* Now we have unmatchable (not generative, not injective) and matchable (generative, injective), it feels incomplete not to have annotations for generative-but-not-injective and injective-but-not-generative arrows. While generativity annotation (and checking!) is effectively an entirely new chunk of work, it’s a shame that we have the syntax to specify the injectivity of a type family when we create it, but not when we consume it. I have some concrete examples of where having to declare injective type families as fully unmatchable leads to ambiguity that I can share if anyone is interested, but my understanding from Csongor is that this is a deceptively large amount of work, and definitely out of scope for this particular proposal.

Looking down my list, these are the two thoughts I have that haven’t been explicitly covered in full somewhere in the GitHub thread, and I feel they could be summarised as an implementation suggestion and a feature request. All of which is to say, I’m still very much in support of the proposal, and extremely excited to start using it.

Thanks,
Tom

On 2 Dec 2020, at 15:30, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:

Dear all,

I'm a bit worried by the limited response from the committee on this proposal. It is a non-trivial proposal, and I think it deserves more eyes. So please have a look at them so that we can commit to this with confidence.

/Arnaud

On Tue, Dec 1, 2020 at 7:28 PM Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
This thread has seen only positive responses, and with no responses for the past 6 days. I'm thus inclined to accept the proposal.

However, there are open questions around the following points:
* the concrete syntax (pending discussion on #370)
* defaulting rules (as raised by Alejandro in this thread)

Conveniently, these are both listed as Unresolved Questions in the proposal itself. We need a way of resolving these questions. The syntax question may become clearer once we know what to do about #370. The defaulting question is harder. I vote to return to this question once #378 has settled somewhat -- but even then, it will be hard. Still, I think we should move forward with accepting the main proposal, and we can continue to debate the defaulting strategy in a further thread, perhaps in parallel with reviewing the (already existing) implementation.

I will accept this proposal as written at the end of the week, barring commentary here (or on GitHub) to stop me.

Thanks!
Richard

> On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
>
> I'm on board with unsaturated type families.
>
> Like Linear Haskell, it's quite a "big" proposal, but accepting it is compatible with idea of Haskell as a laboratory for exploration.  I think we should flag it as experimental, with the implication that details are liable to change as we gain experience.
>
> Like others, I'd like us to converge on #370 before fixing syntax.
>
> I don’t have a strong opinion about the defaulting stuff.
>
> Declaration of interest: I'm a co-author on the paper.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Richard Eisenberg
> |  Sent: 20 November 2020 19:36
> |  To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-
> |  committee at haskell.org<mailto:committee at haskell.org>>
> |  Subject: [ghc-steering-committee] Unsaturated type families (#242)
> |
> |  Hi committee,
> |
> |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
> |
> |  Proposal:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com<http://ub.com/>%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
> |  families%2Fproposals%2F0000-unsaturated-type-
> |  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cbd9e62e3137e
> |  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374
> |  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> |  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9ZXOjmE
> |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
> |  ICFP'19 paper:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> |  microsoft.com<http://microsoft.com/>%2Fen-
> |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-type-
> |  families-icfp-
> |  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cbd9e62e3137e4038
> |  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741497
> |  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fPAr498F
> |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
> |  Discussion:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com<http://ub.com/>%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cbd
> |  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9N0y7l
> |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
> |
> |  The central idea is to allow type functions (both type families and
> |  type synonyms) to appear unsaturated. (Currently, all type functions
> |  are required syntactically to be applied to all parameters they are
> |  declared with.) This poses a problem for type inference, as detailed
> |  in both the proposal and the paper. The key question: if we have (f a
> |  ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g
> |  is a type function. This proposal thus describes a mechanism to
> |  introduce a new flavor of arrow, such that we can identify type
> |  functions by their kind. Specifically, we have regular types like
> |  Maybe :: Type -> @M Type (where the M stands for "matchable"), but
> |  type functions like F :: Type -> @U Type (where the U stands for
> |  "unmatchable"). Unmatchable applications can not be decomposed during
> |  type inference.
> |
> |  Much of the proposal is concerned with backward-compatibility: most
> |  users will not want to write @M or @U after each of their arrows, so
> |  the proposal describes ways of defaulting this behavior to match
> |  (most) programmers' expectations.
> |
> |  The proposal also includes matchability polymorphism, the ability to
> |  abstract over a matchability parameter.
> |
> |  Pros:
> |  + This proposal greatly increases the expressiveness of Haskell's type
> |  system.
> |  + With this proposal, we can finally do proper functional programming
> |  in types, rather than just in terms.
> |  + This proposal is a key ingredient toward having dependent types, as
> |  + unsaturated functions are commonplace in terms, and thus should also
> |  be supported in types. (Allowing unsaturated functions in types was a
> |  key difference between Adam Gundry's proposal for dependent types
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadam
> |  .gundry.co.uk<http://gundry.co.uk/>%2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40microsoft
> |  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011
> |  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> |  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> |  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=0,
> |  which requires a notion of a subset of the type and term languages
> |  shared in common, and mine, which makes no distinction between terms
> |  and types.) There is a prototype implementation.
> |  + The ideas are backed up by peer-reviewed research.
> |  + Despite focusing on type families, this work applies equally to
> |  ordinary functions which might be used in types once we have stronger
> |  support for dependent types.
> |
> |  Cons:
> |  - This adds a new dimension of complexity to our kind system, by
> |  separating out matchable and unmatchable arrows.
> |  - The rules for defaulting appear convenient in practice, but are
> |  somewhat arbitrary.
> |  - The rules for defaulting care about context -- does an arrow appear
> |  in the type of a term or the type of a type? These rules thus go
> |  against the spirit of #378, which advocates for not accepting features
> |  that distinguish between types and terms.
> |
> |  Recommendation: With reservations, I recommend acceptance. I think
> |  that the power to use higher-order programming should not be
> |  restricted to terms, and allowing unsaturated functions at compile
> |  time is necessary in order to have convenient dependent types.
> |  However, I am concerned about the extra complexity of matchability. A
> |  key open question for me is how much matchability is apparent to users
> |  -- even ones using some higher-order type-level programming. If
> |  matchability is pervasive, then I would lean against. But my
> |  expectation is that matchability fades into the background -- much
> |  like levity polymorphism (unless you want it).
> |
> |  Open question: What to do about syntax? The proposed syntax is
> |  sensible. However, #370 suggests an alternative syntax that might be
> |  more forward-thinking.
> |
> |  Richard
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org<http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cbd9e62e3137e403
> |  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374149
> |  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0%2BOib
> |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201202/656c609d/attachment-0001.html>

From mail at joachim-breitner.de  Wed Dec  2 18:24:32 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 Dec 2020 19:24:32 +0100
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
 <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
Message-ID: <85cb1dda4fcd599b6930da5e6806c48dd83fcb9d.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 02.12.2020, 16:30 +0100 schrieb Spiwack, Arnaud:
> I'm a bit worried by the limited response from the committee on this
> proposal. It is a non-trivial proposal, and I think it deserves more
> eyes. So please have a look at them so that we can commit to this
> with confidence.


it is above my head to commit with confidence.
Yes, I want them!

Do I want the matchability kind (and not subtyping)? Do I want
matchability-polymorphism? Are these the right defaults? 
I don't know!

So if the expects say “that's the best we can do”, then all for it. If
the experts say “this there are other corner in the design space”, and
maybe some are simpler/more elegant/what not? Then I can comment.

BTW, https://github.com/ghc-proposals/ghc-proposals/pull/242#issuecomment-736738891 is unanswerd yet.

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



From eric at seidel.io  Thu Dec  3 02:29:41 2020
From: eric at seidel.io (Eric Seidel)
Date: Wed, 02 Dec 2020 21:29:41 -0500
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
 <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
Message-ID: <73334e5f-e1d3-459b-8ab8-1ff8cdc82c0c@www.fastmail.com>

Apologies for being slow, I've left a number of questions on GitHub, mostly asking for clarification on various points.

I'm also generally in favor of this proposal, though like others I have concerns around the defaulting strategies. Mine are mostly around the large number of rules that I'll have to keep in my head if I need to start caring about matchabilites. But I'd be happy with some sort of provisional acceptance, subject to resolving the syntax and defaulting rules later.

On Wed, Dec 2, 2020, at 10:30, Spiwack, Arnaud wrote:
> Dear all,
> 
> I'm a bit worried by the limited response from the committee on this 
> proposal. It is a non-trivial proposal, and I think it deserves more 
> eyes. So please have a look at them so that we can commit to this with 
> confidence.
> 
> /Arnaud
> 
> On Tue, Dec 1, 2020 at 7:28 PM Richard Eisenberg <rae at richarde.dev> wrote:
> > This thread has seen only positive responses, and with no responses for the past 6 days. I'm thus inclined to accept the proposal.
> > 
> > However, there are open questions around the following points:
> > * the concrete syntax (pending discussion on #370)
> > * defaulting rules (as raised by Alejandro in this thread)
> > 
> > Conveniently, these are both listed as Unresolved Questions in the proposal itself. We need a way of resolving these questions. The syntax question may become clearer once we know what to do about #370. The defaulting question is harder. I vote to return to this question once #378 has settled somewhat -- but even then, it will be hard. Still, I think we should move forward with accepting the main proposal, and we can continue to debate the defaulting strategy in a further thread, perhaps in parallel with reviewing the (already existing) implementation.
> > 
> > I will accept this proposal as written at the end of the week, barring commentary here (or on GitHub) to stop me.
> > 
> > Thanks!
> > Richard
> > 
> > > On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > > 
> > > I'm on board with unsaturated type families.
> > > 
> > > Like Linear Haskell, it's quite a "big" proposal, but accepting it is compatible with idea of Haskell as a laboratory for exploration.  I think we should flag it as experimental, with the implication that details are liable to change as we gain experience.
> > > 
> > > Like others, I'd like us to converge on #370 before fixing syntax.
> > > 
> > > I don’t have a strong opinion about the defaulting stuff.
> > > 
> > > Declaration of interest: I'm a co-author on the paper.
> > > 
> > > Simon
> > > 
> > > |  -----Original Message-----
> > > |  From: ghc-steering-committee <ghc-steering-committee-
> > > |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> > > |  Sent: 20 November 2020 19:36
> > > |  To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-
> > > |  committee at haskell.org>
> > > |  Subject: [ghc-steering-committee] Unsaturated type families (#242)
> > > |  
> > > |  Hi committee,
> > > |  
> > > |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
> > > |  
> > > |  Proposal:
> > > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > > |  ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
> > > |  families%2Fproposals%2F0000-unsaturated-type-
> > > |  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e
> > > |  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374
> > > |  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > |  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9ZXOjmE
> > > |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
> > > |  ICFP'19 paper:
> > > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > |  microsoft.com%2Fen-
> > > |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-type-
> > > |  families-icfp-
> > > |  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e4038
> > > |  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741497
> > > |  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > > |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fPAr498F
> > > |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
> > > |  Discussion:
> > > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > > |  ub.com%2Fghc-proposals%2Fghc-
> > > |  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd
> > > |  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> > > |  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > > |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9N0y7l
> > > |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
> > > |  
> > > |  The central idea is to allow type functions (both type families and
> > > |  type synonyms) to appear unsaturated. (Currently, all type functions
> > > |  are required syntactically to be applied to all parameters they are
> > > |  declared with.) This poses a problem for type inference, as detailed
> > > |  in both the proposal and the paper. The key question: if we have (f a
> > > |  ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g
> > > |  is a type function. This proposal thus describes a mechanism to
> > > |  introduce a new flavor of arrow, such that we can identify type
> > > |  functions by their kind. Specifically, we have regular types like
> > > |  Maybe :: Type -> @M Type (where the M stands for "matchable"), but
> > > |  type functions like F :: Type -> @U Type (where the U stands for
> > > |  "unmatchable"). Unmatchable applications can not be decomposed during
> > > |  type inference.
> > > |  
> > > |  Much of the proposal is concerned with backward-compatibility: most
> > > |  users will not want to write @M or @U after each of their arrows, so
> > > |  the proposal describes ways of defaulting this behavior to match
> > > |  (most) programmers' expectations.
> > > |  
> > > |  The proposal also includes matchability polymorphism, the ability to
> > > |  abstract over a matchability parameter.
> > > |  
> > > |  Pros:
> > > |  + This proposal greatly increases the expressiveness of Haskell's type
> > > |  system.
> > > |  + With this proposal, we can finally do proper functional programming
> > > |  in types, rather than just in terms.
> > > |  + This proposal is a key ingredient toward having dependent types, as
> > > |  + unsaturated functions are commonplace in terms, and thus should also
> > > |  be supported in types. (Allowing unsaturated functions in types was a
> > > |  key difference between Adam Gundry's proposal for dependent types
> > > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadam
> > > |  .gundry.co.uk%2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40microsoft
> > > |  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011
> > > |  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > > |  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> > > |  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=0,
> > > |  which requires a notion of a subset of the type and term languages
> > > |  shared in common, and mine, which makes no distinction between terms
> > > |  and types.) There is a prototype implementation.
> > > |  + The ideas are backed up by peer-reviewed research.
> > > |  + Despite focusing on type families, this work applies equally to
> > > |  ordinary functions which might be used in types once we have stronger
> > > |  support for dependent types.
> > > |  
> > > |  Cons:
> > > |  - This adds a new dimension of complexity to our kind system, by
> > > |  separating out matchable and unmatchable arrows.
> > > |  - The rules for defaulting appear convenient in practice, but are
> > > |  somewhat arbitrary.
> > > |  - The rules for defaulting care about context -- does an arrow appear
> > > |  in the type of a term or the type of a type? These rules thus go
> > > |  against the spirit of #378, which advocates for not accepting features
> > > |  that distinguish between types and terms.
> > > |  
> > > |  Recommendation: With reservations, I recommend acceptance. I think
> > > |  that the power to use higher-order programming should not be
> > > |  restricted to terms, and allowing unsaturated functions at compile
> > > |  time is necessary in order to have convenient dependent types.
> > > |  However, I am concerned about the extra complexity of matchability. A
> > > |  key open question for me is how much matchability is apparent to users
> > > |  -- even ones using some higher-order type-level programming. If
> > > |  matchability is pervasive, then I would lean against. But my
> > > |  expectation is that matchability fades into the background -- much
> > > |  like levity polymorphism (unless you want it).
> > > |  
> > > |  Open question: What to do about syntax? The proposed syntax is
> > > |  sensible. However, #370 suggests an alternative syntax that might be
> > > |  more forward-thinking.
> > > |  
> > > |  Richard
> > > |  _______________________________________________
> > > |  ghc-steering-committee mailing list
> > > |  ghc-steering-committee at haskell.org
> > > |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > > |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e403
> > > |  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374149
> > > |  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > > |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0%2BOib
> > > |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From simonpj at microsoft.com  Thu Dec  3 08:27:56 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2020 08:27:56 +0000
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <73334e5f-e1d3-459b-8ab8-1ff8cdc82c0c@www.fastmail.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
 <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
 <73334e5f-e1d3-459b-8ab8-1ff8cdc82c0c@www.fastmail.com>
Message-ID: <VI1PR83MB0222DA10AF230ECEB80EE9E4ADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I have written a comment on the GitHub thread
https://github.com/ghc-proposals/ghc-proposals/pull/242#issuecomment-737551909

I argue for acceptance, but I suggest that we might want to start distinguishing "experimental proposals" from normal proposals.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Eric Seidel
|  Sent: 03 December 2020 02:30
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Unsaturated type families (#242)
|  
|  Apologies for being slow, I've left a number of questions on GitHub,
|  mostly asking for clarification on various points.
|  
|  I'm also generally in favor of this proposal, though like others I
|  have concerns around the defaulting strategies. Mine are mostly around
|  the large number of rules that I'll have to keep in my head if I need
|  to start caring about matchabilites. But I'd be happy with some sort
|  of provisional acceptance, subject to resolving the syntax and
|  defaulting rules later.
|  
|  On Wed, Dec 2, 2020, at 10:30, Spiwack, Arnaud wrote:
|  > Dear all,
|  >
|  > I'm a bit worried by the limited response from the committee on this
|  > proposal. It is a non-trivial proposal, and I think it deserves more
|  > eyes. So please have a look at them so that we can commit to this
|  with
|  > confidence.
|  >
|  > /Arnaud
|  >
|  > On Tue, Dec 1, 2020 at 7:28 PM Richard Eisenberg <rae at richarde.dev>
|  wrote:
|  > > This thread has seen only positive responses, and with no
|  responses for the past 6 days. I'm thus inclined to accept the
|  proposal.
|  > >
|  > > However, there are open questions around the following points:
|  > > * the concrete syntax (pending discussion on #370)
|  > > * defaulting rules (as raised by Alejandro in this thread)
|  > >
|  > > Conveniently, these are both listed as Unresolved Questions in the
|  proposal itself. We need a way of resolving these questions. The
|  syntax question may become clearer once we know what to do about #370.
|  The defaulting question is harder. I vote to return to this question
|  once #378 has settled somewhat -- but even then, it will be hard.
|  Still, I think we should move forward with accepting the main
|  proposal, and we can continue to debate the defaulting strategy in a
|  further thread, perhaps in parallel with reviewing the (already
|  existing) implementation.
|  > >
|  > > I will accept this proposal as written at the end of the week,
|  barring commentary here (or on GitHub) to stop me.
|  > >
|  > > Thanks!
|  > > Richard
|  > >
|  > > > On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > > >
|  > > > I'm on board with unsaturated type families.
|  > > >
|  > > > Like Linear Haskell, it's quite a "big" proposal, but accepting
|  it is compatible with idea of Haskell as a laboratory for exploration.
|  I think we should flag it as experimental, with the implication that
|  details are liable to change as we gain experience.
|  > > >
|  > > > Like others, I'd like us to converge on #370 before fixing
|  syntax.
|  > > >
|  > > > I don’t have a strong opinion about the defaulting stuff.
|  > > >
|  > > > Declaration of interest: I'm a co-author on the paper.
|  > > >
|  > > > Simon
|  > > >
|  > > > |  -----Original Message-----
|  > > > |  From: ghc-steering-committee <ghc-steering-committee-
|  > > > | bounces at haskell.org> On Behalf Of Richard Eisenberg
|  > > > |  Sent: 20 November 2020 19:36
|  > > > |  To: Simon Peyton Jones via ghc-steering-committee
|  > > > | <ghc-steering-  committee at haskell.org>
|  > > > |  Subject: [ghc-steering-committee] Unsaturated type families
|  > > > | (#242)
|  > > > |
|  > > > |  Hi committee,
|  > > > |
|  > > > |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
|  > > > |
|  > > > |  Proposal:
|  > > > |
|  > > > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
|  > > > | 2Fgith
|  > > > |  ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
|  > > > |  families%2Fproposals%2F0000-unsaturated-type-
|  > > > |
|  > > > |
|  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62
|  > > > | e3137e
|  > > > |
|  > > > |
|  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%
|  > > > | 7C6374
|  > > > |
|  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  > > > | joiV2l
|  > > > |
|  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9
|  > > > | ZXOjmE
|  > > > |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
|  > > > |  ICFP'19 paper:
|  > > > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
|  > > > |  microsoft.com%2Fen-
|  > > > |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-
|  type-
|  > > > |  families-icfp-
|  > > > |
|  > > > |
|  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e313
|  > > > | 7e4038
|  > > > |
|  > > > |
|  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63
|  > > > | 741497
|  > > > |
|  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  > > > | 2luMzI
|  > > > |
|  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fP
|  > > > | Ar498F
|  > > > |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
|  > > > |  Discussion:
|  > > > |
|  > > > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
|  > > > | 2Fgith
|  > > > |  ub.com%2Fghc-proposals%2Fghc-
|  > > > |
|  > > > |
|  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.co
|  > > > | m%7Cbd
|  > > > |
|  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db4
|  > > > | 7%7C1%
|  > > > |
|  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
|  > > > | wMDAiL
|  > > > |
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C
|  > > > | 9N0y7l
|  > > > |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
|  > > > |
|  > > > |  The central idea is to allow type functions (both type
|  families
|  > > > | and  type synonyms) to appear unsaturated. (Currently, all
|  type
|  > > > | functions  are required syntactically to be applied to all
|  > > > | parameters they are  declared with.) This poses a problem for
|  > > > | type inference, as detailed  in both the proposal and the
|  paper.
|  > > > | The key question: if we have (f a  ~ g b), can we conclude (f
|  ~
|  > > > | g) and (a ~ b)? Not if either of f or g  is a type function.
|  > > > | This proposal thus describes a mechanism to  introduce a new
|  > > > | flavor of arrow, such that we can identify type  functions by
|  > > > | their kind. Specifically, we have regular types like  Maybe ::
|  > > > | Type -> @M Type (where the M stands for "matchable"), but
|  type
|  > > > | functions like F :: Type -> @U Type (where the U stands for
|  > > > | "unmatchable"). Unmatchable applications can not be decomposed
|  during  type inference.
|  > > > |
|  > > > |  Much of the proposal is concerned with backward-
|  compatibility:
|  > > > | most  users will not want to write @M or @U after each of
|  their
|  > > > | arrows, so  the proposal describes ways of defaulting this
|  > > > | behavior to match
|  > > > |  (most) programmers' expectations.
|  > > > |
|  > > > |  The proposal also includes matchability polymorphism, the
|  > > > | ability to  abstract over a matchability parameter.
|  > > > |
|  > > > |  Pros:
|  > > > |  + This proposal greatly increases the expressiveness of
|  > > > | Haskell's type  system.
|  > > > |  + With this proposal, we can finally do proper functional
|  > > > | programming  in types, rather than just in terms.
|  > > > |  + This proposal is a key ingredient toward having dependent
|  > > > | types, as  + unsaturated functions are commonplace in terms,
|  and
|  > > > | thus should also  be supported in types. (Allowing unsaturated
|  > > > | functions in types was a  key difference between Adam Gundry's
|  > > > | proposal for dependent types
|  > > > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
|  > > > | 2Fadam
|  > > > |
|  .gundry.co.uk%2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40mic
|  > > > | rosoft
|  > > > |
|  > > > |
|  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d
|  > > > | 7cd011
|  > > > |
|  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIj
|  > > > | oiMC4w
|  > > > |
|  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
|  > > > | p;sdat
|  > > > |
|  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=
|  > > > | 0,  which requires a notion of a subset of the type and term
|  > > > | languages  shared in common, and mine, which makes no
|  > > > | distinction between terms  and types.) There is a prototype
|  > > > | implementation.
|  > > > |  + The ideas are backed up by peer-reviewed research.
|  > > > |  + Despite focusing on type families, this work applies
|  equally
|  > > > | to  ordinary functions which might be used in types once we
|  have
|  > > > | stronger  support for dependent types.
|  > > > |
|  > > > |  Cons:
|  > > > |  - This adds a new dimension of complexity to our kind system,
|  > > > | by  separating out matchable and unmatchable arrows.
|  > > > |  - The rules for defaulting appear convenient in practice, but
|  > > > | are  somewhat arbitrary.
|  > > > |  - The rules for defaulting care about context -- does an
|  arrow
|  > > > | appear  in the type of a term or the type of a type? These
|  rules
|  > > > | thus go  against the spirit of #378, which advocates for not
|  > > > | accepting features  that distinguish between types and terms.
|  > > > |
|  > > > |  Recommendation: With reservations, I recommend acceptance. I
|  > > > | think  that the power to use higher-order programming should
|  not
|  > > > | be  restricted to terms, and allowing unsaturated functions at
|  > > > | compile  time is necessary in order to have convenient
|  dependent types.
|  > > > |  However, I am concerned about the extra complexity of
|  > > > | matchability. A  key open question for me is how much
|  > > > | matchability is apparent to users
|  > > > |  -- even ones using some higher-order type-level programming.
|  If
|  > > > | matchability is pervasive, then I would lean against. But my
|  > > > | expectation is that matchability fades into the background --
|  > > > | much  like levity polymorphism (unless you want it).
|  > > > |
|  > > > |  Open question: What to do about syntax? The proposed syntax
|  is
|  > > > | sensible. However, #370 suggests an alternative syntax that
|  > > > | might be  more forward-thinking.
|  > > > |
|  > > > |  Richard
|  > > > |  _______________________________________________
|  > > > |  ghc-steering-committee mailing list
|  > > > | ghc-steering-committee at haskell.org
|  > > > |
|  > > > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
|  > > > | 2Fmail
|  > > > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  > > > |
|  > > > |
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e31
|  > > > | 37e403
|  > > > |
|  > > > |
|  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6
|  > > > | 374149
|  > > > |
|  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
|  > > > | V2luMz
|  > > > |
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0
|  > > > | %2BOib
|  > > > |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0
|  > >
|  > > _______________________________________________
|  > > ghc-steering-committee mailing list
|  > > ghc-steering-committee at haskell.org
|  > >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  > > il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committ
|  > >
|  ee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C692997bb67394e8cab4f
|  > >
|  08d897335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374255946
|  > >
|  59710772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
|  > >
|  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6s
|  > > imMc%2Ffai00Qi9%2B8OIsmGPQp0%3D&amp;reserved=0
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at 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%7C692997bb67394e8cab4f08d897
|  >
|  335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425594659710772
|  >
|  %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
|  >
|  k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6simMc%2Ffai00
|  > Qi9%2B8OIsmGPQp0%3D&amp;reserved=0
|  >
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C692997bb67394e8
|  cab4f08d897335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374255
|  94659710772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6si
|  mMc%2Ffai00Qi9%2B8OIsmGPQp0%3D&amp;reserved=0

From mail at joachim-breitner.de  Thu Dec  3 08:51:33 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 09:51:33 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
Message-ID: <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>

Hi,

thanks all for various inputs, I’ll update my votes as follows:

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


I’d also like 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 this sways at least least those who have this on “maybe”
(Alejandro, Arnaud, Iavor and SPJ).


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



From arnaud.spiwack at tweag.io  Thu Dec  3 09:05:39 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Dec 2020 10:05:39 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
Message-ID: <CAH6fHQk4=wooB9nTu0Z1PAfnnJ8GLV7Ussdeyoox8n5QFh+RJQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/f0a8bcdc/attachment-0001.html>

From mail at joachim-breitner.de  Thu Dec  3 09:31:18 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 10:31:18 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>

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-ghc2021.rst#data
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From trupill at gmail.com  Thu Dec  3 09:40:52 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 3 Dec 2020 01:40:52 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
Message-ID: <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>

 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 <mail at 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-ghc2021.rst#data
> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/dc40f620/attachment.html>

From simonpj at microsoft.com  Thu Dec  3 10:03:11 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2020 10:03:11 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
Message-ID: <VI1PR83MB02223BF28442454CF846C4EBADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 03 December 2020 09:41
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at 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 <mail at joachim-breitner.de<mailto:mail at 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-ghc2021.rst#data<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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdxLRYi8jFlwCdrXzDjvDw%2B098%2B9tRWvg6KJt7NT02I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/41ffcc18/attachment-0001.html>

From bravit111 at gmail.com  Thu Dec  3 10:14:09 2020
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Thu, 3 Dec 2020 13:14:09 +0300
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <CALpVSmP5xHmKLz-DtNkWhrbciDoqvu2E9efUHuTjspHGuMB6iQ@mail.gmail.com>

Hi,

Following the discussions I've decided to update my vote:

-- Updates:
ConstrainedClassMethods: yes
ForeignFunctionInterface: yes
NamedWildCards: yes
OverloadedLists: yes
OverloadedStrings: yes
PolyKinds: yes
PostfixOperators: yes
MonoLocalBinds: yes

-- The rest goes without changes
-- Definitely 'yes'

InstanceSigs: yes
-- I have a special feeling about this one,
-- it is extremely helpful when teaching

BangPatterns: yes
BinaryLiterals: yes
NegativeLiterals: yes
HexFloatLiterals: yes
NumericUnderscores: yes
DeriveDataTypeable: yes
DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveLift: yes
DeriveTraversable: yes
DerivingStrategies: yes
DerivingVia: yes
GeneralisedNewtypeDeriving: yes
EmptyCase: yes
EmptyDataDecls: yes
EmptyDataDeriving: yes
ExplicitForAll: yes
ConstraintKinds: yes
DataKinds: yes
FlexibleContexts: yes
FlexibleInstances: yes
GADTSyntax: yes
GADTs: yes
ImportQualifiedPost: yes
MultiParamTypeClasses: yes
NamedFieldPuns: yes
RankNTypes: yes
RecordWildCards: yes
ScopedTypeVariables: yes
StandaloneDeriving: yes
StarIsType: yes
TupleSections: yes
TypeApplications: yes
TypeFamilies: yes
TypeOperators: yes
TypeSynonymInstances: yes
ViewPatterns: yes
KindSignatures: yes
LambdaCase: yes
MonadFailDesugaring: yes



-- Not now

AllowAmbiguousTypes: no
ApplicativeDo: no
Arrows: no
BlockArguments: no
CApiFFI: no
CPP: no
CUSKs: no
DatatypeContexts: no
DefaultSignatures: no
DeriveAnyClass: no
DisambiguateRecordFields: no
DuplicateRecordFields: no
ExistentialQuantification: no
ExplicitNamespaces: no
ExtendedDefaultRules: no
FunctionalDependencies: no
GHCForeignImportPrim: no
ImplicitParams: no
ImpredicativeTypes: no
IncoherentInstances: no
InterruptibleFFI: no
LexicalNegation: no
LiberalTypeSynonyms: no
LinearTypes: no
MagicHash: no
MonadComprehensions: no
MultiWayIf: no
NPlusKPatterns: no
NoImplicitPrelude: no
NoMonomorphismRestriction: no
NoPatternGuards: no
NoTraditionalRecordSyntax: no
NondecreasingIndentation: no
NullaryTypeClasses: no
NumDecimals: no
OverlappingInstances: no
OverloadedLabels: no
PackageImports: no
ParallelListComp: no
PartialTypeSignatures: no
PatternSynonyms: no
QualifiedDo: no
QuantifiedConstraints: no
QuasiQuotes: no
RebindableSyntax: no
RecursiveDo: no
RoleAnnotations: no
Safe: no
StandaloneKindSignatures: no
StaticPointers: no
Strict: no
StrictData: no
TemplateHaskell: no
TemplateHaskellQuotes: no
TransformListComp: no
Trustworthy: no
TypeFamilyDependencies: no
TypeInType: no
UnboxedSums: no
UnboxedTuples: no
UndecidableInstances: no
UndecidableSuperClasses: no
UnicodeSyntax: no
UnliftedFFITypes: no
UnliftedNewtypes: no
Unsafe: no

Vitaly

вт, 24 нояб. 2020 г. в 12:34, Joachim Breitner <mail at joachim-breitner.de>:

> Dear Committee,
>
> the requested data (hackage and survey) is in, has been aggregated,
> cooked, seasoned and is ready for consumption. 116 extensions are
> waiting on your assessment, so time to vote!
>
> ## Procedure
>
> Please vote by email to this list, in a response to this thread.
>
> I want to make tallying easy and automatic, and my code will consider
> an extension Foo voted for if you write "Foo: yes" on its own line.
> This means you can include rationales, write "Foo: maybe" and "Foo: no"
> to remind yourself and others that about where you are, and you can
> safely quote other’s mails. For example, if you write:
>
> ---- begin
> example ----
>
> Easy ones:
>
> DeriveFooBar: yes
> OverloadedBen: no
>
> These ones are tricky:
>
> ImplicitExceptions: yes
>   I know nobody likes that one, but I do.
>
> RandomEvaluationOrder: maybe
>   Not sure about this one, here is why…
>
>
> > Richard wrote:
> > DependentHaskell: yes
> > Rationale: See my thesis
>
> I’m not convinced yet, tell me more, so
> DependentHaskell: maybe
>
> ---- end example ----
>
> then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes”
> matters, “no”, “maybe” and “later” are all ignored.
>
> I will shortly send my first ballot around. Also see the end of this
> mail for a copy’n’paste template.
>
> You can update your vote as often as you want. Please always send your
> full votes (I will only consider your latest email). I encourage you to
> do that early, e.g. maybe start with a mail where you list the obvious
> yes and nos, and keep some at maybe and then refine.
>
> The timeline says first votes should be in within two weeks, and then a
> bit more to refine. But the earlier the merrier!
>
> The quota is 8. In particular, if everyone votes (and I hope everyone
> will), an extension won’t make it this round if 4 don’t include it.
>
> ## Data
>
> Please see
>
> https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data
> for the data, including explanations. It is intentionally not sorted by
> the data, as the choice of ranking function would already be quite
> influencing.
>
> You may want to play around with that data, e.g. sort it by your own
> criteria etc. I looked long for an online service where I can upload
> the data and allow you to explore it, but then I noticed that that's a
> bit stupid, since we all probably can do it best with Haskell.
>
> So I made it easy to load the data into GHCi, see the instructions at
>
> https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md
> which allow you, for example, to do this
>
> *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $
> take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts)
> AllowAmbiguousTypes: 195
> CPP: 192
> IncoherentInstances: 176
> Arrows: 156
> Strict: 153
> ImplicitParams: 147
> UndecidableInstances: 144
> OverlappingInstances: 144
> Unsafe: 139
> TemplateHaskell: 137
>
> Of course, if someone wants to upload the data somewhere and share
> that, that's also useful.
>
>
> Let me know if some of this doesn't quite work for you, and should be
> improved. Maybe we need a web form instead of mails?
>
>
> ## PS: Blank ballot
>
> To start, you could copy the following into an email
>
> AllowAmbiguousTypes: maybe
> ApplicativeDo: maybe
> Arrows: maybe
> BangPatterns: maybe
> BinaryLiterals: maybe
> BlockArguments: maybe
> CApiFFI: maybe
> CPP: maybe
> CUSKs: maybe
> ConstrainedClassMethods: maybe
> ConstraintKinds: maybe
> DataKinds: maybe
> DatatypeContexts: maybe
> DefaultSignatures: maybe
> DeriveAnyClass: maybe
> DeriveDataTypeable: maybe
> DeriveFoldable: maybe
> DeriveFunctor: maybe
> DeriveGeneric: maybe
> DeriveLift: maybe
> DeriveTraversable: maybe
> DerivingStrategies: maybe
> DerivingVia: maybe
> DisambiguateRecordFields: maybe
> DuplicateRecordFields: maybe
> EmptyCase: maybe
> EmptyDataDecls: maybe
> EmptyDataDeriving: maybe
> ExistentialQuantification: maybe
> ExplicitForAll: maybe
> ExplicitNamespaces: maybe
> ExtendedDefaultRules: maybe
> FlexibleContexts: maybe
> FlexibleInstances: maybe
> ForeignFunctionInterface: maybe
> FunctionalDependencies: maybe
> GADTSyntax: maybe
> GADTs: maybe
> GHCForeignImportPrim: maybe
> GeneralisedNewtypeDeriving: maybe
> HexFloatLiterals: maybe
> ImplicitParams: maybe
> ImportQualifiedPost: maybe
> ImpredicativeTypes: maybe
> IncoherentInstances: maybe
> InstanceSigs: maybe
> InterruptibleFFI: maybe
> KindSignatures: maybe
> LambdaCase: maybe
> LexicalNegation: maybe
> LiberalTypeSynonyms: maybe
> LinearTypes: maybe
> MagicHash: maybe
> MonadComprehensions: maybe
> MonadFailDesugaring: maybe
> MonoLocalBinds: maybe
> MultiParamTypeClasses: maybe
> MultiWayIf: maybe
> NPlusKPatterns: maybe
> NamedFieldPuns: maybe
> NamedWildCards: maybe
> NegativeLiterals: maybe
> NoImplicitPrelude: maybe
> NoMonomorphismRestriction: maybe
> NoPatternGuards: maybe
> NoTraditionalRecordSyntax: maybe
> NondecreasingIndentation: maybe
> NullaryTypeClasses: maybe
> NumDecimals: maybe
> NumericUnderscores: maybe
> OverlappingInstances: maybe
> OverloadedLabels: maybe
> OverloadedLists: maybe
> OverloadedStrings: maybe
> PackageImports: maybe
> ParallelListComp: maybe
> PartialTypeSignatures: maybe
> PatternSynonyms: maybe
> PolyKinds: maybe
> PostfixOperators: maybe
> QualifiedDo: maybe
> QuantifiedConstraints: maybe
> QuasiQuotes: maybe
> RankNTypes: maybe
> RebindableSyntax: maybe
> RecordWildCards: maybe
> RecursiveDo: maybe
> RoleAnnotations: maybe
> Safe: maybe
> ScopedTypeVariables: maybe
> StandaloneDeriving: maybe
> StandaloneKindSignatures: maybe
> StarIsType: maybe
> StaticPointers: maybe
> Strict: maybe
> StrictData: maybe
> TemplateHaskell: maybe
> TemplateHaskellQuotes: maybe
> TransformListComp: maybe
> Trustworthy: maybe
> TupleSections: maybe
> TypeApplications: maybe
> TypeFamilies: maybe
> TypeFamilyDependencies: maybe
> TypeInType: maybe
> TypeOperators: maybe
> TypeSynonymInstances: maybe
> UnboxedSums: maybe
> UnboxedTuples: maybe
> UndecidableInstances: maybe
> UndecidableSuperClasses: maybe
> UnicodeSyntax: maybe
> UnliftedFFITypes: maybe
> UnliftedNewtypes: maybe
> Unsafe: maybe
> ViewPatterns: maybe
>
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/bada7a0a/attachment.html>

From marlowsd at gmail.com  Thu Dec  3 10:29:24 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Dec 2020 10:29:24 +0000
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>
References: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
 <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>
Message-ID: <CANsrgPL3fqRpojg0ej-Rt1O0zb_0dL2uDG9aWTkFOz2hh9RXuw@mail.gmail.com>

My understanding of what happened in C compilers is that the optimisers
want to do some dataflow analysis to determine the ranges of values that
variables can take, in order to eliminate unnecessary conditionals and so
forth. These analyses are severely crippled if you can't assume the absence
of undefined behaviour in C/C++, because most arithmetic operations have
undefined behaviour: overflow is undefined, for example.

We don't do this kind of analysis in GHC at the moment, and we don't have
quite so much undefined behaviour floating around. But I can imagine
similar issues might arise. I mean, we most definitely assume that the
result of `unsafeCoerce#` is a value of the claimed type - what else can
you do? I suppose I'm not really clear on what specifically it would mean
to adopt "illegal but unchecked" as the policy for undefined behaviour.
Does it mean the compiler can't assume anything about the result of an
operation that has any undefined behaviour? That sounds problematic.

Cheers
Simon

On Wed, 2 Dec 2020 at 14:22, Eric Seidel <eric at seidel.io> wrote:

> I think the key distinction between “undefined” as used in C/C++ and what
> I call “illegal but unchecked” is that the optimizer operates under the
> assumption that “undefined” behavior is impossible. This is what leads to
> the bizarre and scary stories that people post about UB, but it also lets
> C/C++ compilers emit much more efficient code in some common places. In
> contrast, an “illegal but unchecked” operation would be left alone by the
> optimizer. The runtime behavior would be unspecified and possibly
> platform-dependent, but still more constrained and predictable than UB.
>
> I agree that unsafe primops are fine, but I’m curious now if GHC optimizes
> based on the assumption that they’re used correctly.
>
> Sent from my iPhone
>
> On Dec 2, 2020, at 08:34, Simon Marlow <marlowsd at gmail.com> wrote:
>
> 
> "Illegal but unchecked" would be fine too, although we do already use the
> term "undefined" in the documentation for various primops.
>
> We've so far taken the approach that undefined behaviour in primops is OK.
> The idea is that libraries built on top can provide a safe and
> fully-defined API. e.g.
>
> * division-by-zero is undefined (libraries are supposed to check before
> invoking the primop)
> * The uncheckedIShift family are undefined for arguments outside the
> allowed bounds
> * unsafeCoerce is undefined when used in certain ways, of course
>
> There are probably more that aren't documented.
>
> Cheers
> Siimon
>
>
> On Tue, 1 Dec 2020 at 18:25, Eric Seidel <eric at seidel.io> wrote:
>
>> Oh I see. I'm always uncomfortable declaring things "undefined" because
>> of how C/C++ compilers can run wild  with code that invokes UB. So I kinda
>> prefer saying that it's "illegal but unchecked".
>>
>> On Tue, Dec 1, 2020, at 12:35, Simon Marlow wrote:
>> > The issue with unsafePerformIO is really just that the proposal says
>> > that it's illegal to use the primops with unsafePerformIO. I don't
>> > think it's possible to make it "illegal" in any meaningful sense,
>> > probably a better way to say it would be "undefined" or "unsupported"
>> > or somesuch.
>> >
>> > Cheers
>> > Simon
>> >
>> > On Mon, 30 Nov 2020 at 01:53, Eric Seidel <eric at seidel.io> wrote:
>> > > This is a very well-written and motivated proposal, and I love that
>> it's just three new primops (really two, plus a tag to add some guard
>> rails). I'm not very familiar with the literature on delimited
>> continuations, but I support going with the most general formulation,
>> especially for primops.
>> > >
>> > > I'm not sure we need to be able to detect all uses of the new primops
>> with unsafePerformIO, it's already a deeply unsafe function. Just another
>> thing that advanced users will need to keep in mind.
>> > >
>> > > On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote:
>> > > > Committee,
>> > > >
>> > > > We have been asked to review
>> > > > #313: Delimited continuation primops
>> > > >
>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
>> > > >
>> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
>> > > >
>> > > > *Summary*
>> > > >
>> > > > The proposal makes no language changes, it only adds three primops
>> > > > <
>> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#proposed-change-specification
>> >.
>> > > >
>> > > > The main motivation is to support building efficient
>> implementations of
>> > > > Algebraic Effect systems, which depend on being able to efficiently
>> > > > capture a continuation. Currently this is done explicitly, which
>> > > > imposes a severe performance penalty.
>> > > >
>> > > > These primops are the minimal support needed to be able to capture
>> a
>> > > > continuation and apply it at runtime, together with some basic type
>> > > > safety via the PromtTag type to ensure that at least we don't
>> replace a
>> > > > continuation with a computation of a different type.  (there are
>> other
>> > > > ways to go wrong with these primops though, they're not a safe
>> > > > interface by themselves: they need to be wrapped in a safe library).
>> > > >
>> > > > The primops are implemented by copying chunks of stack into the
>> heap.
>> > > > This is something that GHC's runtime already does a lot of, so it's
>> not
>> > > > a new concept, although it does require a new closure type and
>> knock-on
>> > > > changes across several files in the runtime (though it's mainly
>> > > > mechanical). There's a prototype implementation here:
>> > > >
>> https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline
>> > > >
>> > > > *Decision*
>> > > > *
>> > > > *
>> > > > I'm going to tentatively recommend acceptance.
>> > > >  * This is a sensible choice for the primtives, being the most
>> general
>> > > > of the alternatives, as explained in the proposal.
>> > > > <
>> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md#operational-semantics
>> >
>> > > >  * Would the new primops impose a significant ongoing maintenance
>> > > > burden? Having looked at the patch, although there are some missing
>> > > > pieces, I don't think the new concepts impose any significant new
>> > > > requirements on other parts of the runtime.
>> > > >  * I suspect there may be some difficulties around unsafePerformIO,
>> so
>> > > > I raised that on the github thread
>> > > > <
>> https://github.com/ghc-proposals/ghc-proposals/pull/313#issuecomment-732181948
>> >
>> > > > Thoughts?
>> > > >
>> > > >
>> > > >
>> > > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>> > > > > Dear Committee,
>> > > > >
>> > > > > this is your secretary speaking:
>> > > > >
>> > > > > Delimited continuation primops
>> > > > > has been proposed by Alexis King
>> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/313
>> > > > >
>> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md
>> > > > >
>> > > > > I’ll propose Simon Marlow as the shepherd.
>> > > > >
>> > > > > Please guide us to a conclusion as outlined in
>> > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> > > > >
>> > > > > Thanks,
>> > > > > Joachim
>> > > > > --
>> > > > > Joachim Breitner
>> > > > >   mail at joachim-breitner.de
>> > > > >   http://www.joachim-breitner.de/
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > ghc-steering-committee mailing list
>> > > > > ghc-steering-committee at haskell.org
>> > > > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > > > _______________________________________________
>> > > > ghc-steering-committee mailing list
>> > > > ghc-steering-committee at haskell.org
>> > > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > > >
>> > > _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/d132c1c7/attachment-0001.html>

From tomjharding at live.co.uk  Thu Dec  3 10:41:04 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Thu, 3 Dec 2020 10:41:04 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <VI1PR83MB02223BF28442454CF846C4EBADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <VI1PR83MB02223BF28442454CF846C4EBADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <55F835BE-C752-425B-AC65-A50BE97448E8@live.co.uk>

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 <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
Sent: 03 December 2020 09:41
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 <mail at joachim-breitner.de<mailto:mail at 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-ghc2021.rst#data<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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdxLRYi8jFlwCdrXzDjvDw%2B098%2B9tRWvg6KJt7NT02I%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/d8e86046/attachment-0001.html>

From marlowsd at gmail.com  Thu Dec  3 10:47:50 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Dec 2020 10:47:50 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
Message-ID: <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>

On Thu, 3 Dec 2020 at 08:51, Joachim Breitner <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/fb18e11b/attachment.html>

From arnaud.spiwack at tweag.io  Thu Dec  3 10:52:48 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Dec 2020 11:52:48 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
 <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>
Message-ID: <CAH6fHQnnFcCHZWtv3MtsW8aXb=FSBhph-C0bM6Lq+_yukeyNyQ@mail.gmail.com>

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 <marlowsd at gmail.com> wrote:

>
>
> On Thu, 3 Dec 2020 at 08:51, Joachim Breitner <mail at joachim-breitner.de>
> 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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/1d62d3e5/attachment-0001.html>

From marlowsd at gmail.com  Thu Dec  3 11:26:09 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Dec 2020 11:26:09 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
Message-ID: <CANsrgPLqDtrtwXPrHeD5BQxHQRv8hTma7RLDfzauY4ufwWGMJA@mail.gmail.com>

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

Cheers
Simon

On Thu, 3 Dec 2020 at 09:31, Joachim Breitner <mail at 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-ghc2021.rst#data
> 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/6d3f9fc1/attachment.html>

From simonpj at microsoft.com  Thu Dec  3 11:59:07 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2020 11:59:07 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CANsrgPLqDtrtwXPrHeD5BQxHQRv8hTma7RLDfzauY4ufwWGMJA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CANsrgPLqDtrtwXPrHeD5BQxHQRv8hTma7RLDfzauY4ufwWGMJA@mail.gmail.com>
Message-ID: <VI1PR83MB02226774C27DE7A5B055A35DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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-alternative<https://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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 03 December 2020 11:26
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
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-alternative<https://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 <mail at joachim-breitner.de<mailto:mail at 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-ghc2021.rst#data<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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at 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%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937688618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z7%2FudmXrboJ9RKKn%2FAXDeknKC0EohWMY1hrzYUYuhJw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/2634f5aa/attachment-0001.html>

From mail at joachim-breitner.de  Thu Dec  3 13:04:03 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 14:04:03 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <VI1PR83MB02226774C27DE7A5B055A35DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CANsrgPLqDtrtwXPrHeD5BQxHQRv8hTma7RLDfzauY4ufwWGMJA@mail.gmail.com>
 <VI1PR83MB02226774C27DE7A5B055A35DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <360b82cdfe40524ad64069fe5106cb7493e4a8b7.camel@joachim-breitner.de>

Am Donnerstag, den 03.12.2020, 11:59 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> 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.

Convinced, will remove my vote for ViewPatterns.

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



From eric at seidel.io  Thu Dec  3 14:50:24 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Dec 2020 09:50:24 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23313=3A_Delimi?=
 =?utf-8?q?ted_continuation_primops=2C_Shepherd=3A_Simon_Marlow?=
In-Reply-To: <CANsrgPL3fqRpojg0ej-Rt1O0zb_0dL2uDG9aWTkFOz2hh9RXuw@mail.gmail.com>
References: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
 <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>
 <CANsrgPL3fqRpojg0ej-Rt1O0zb_0dL2uDG9aWTkFOz2hh9RXuw@mail.gmail.com>
Message-ID: <4f232602-37cf-45c2-930d-841d60fb2d4c@www.fastmail.com>

On Thu, Dec 3, 2020, at 05:29, Simon Marlow wrote:
> My understanding of what happened in C compilers is that the optimisers 
> want to do some dataflow analysis to determine the ranges of values 
> that variables can take, in order to eliminate unnecessary conditionals 
> and so forth. These analyses are severely crippled if you can't assume 
> the absence of undefined behaviour in C/C++, because most arithmetic 
> operations have undefined behaviour: overflow is undefined, for example.

Right, I think what leads to the surprising behavior in C/C++ is that compilers
sometimes use the results of the dataflow analysis in a manner that violates
causality.

For example, removing a NULL check because later on the pointer
is dereferenced unconditionally. I don't think anyone would complain about
the compiler removing NULL checks *after* the dereference, but doing so
before is a bit unsettling. Suppose the NULL check the compiler cleverly
elided was meant to call into a custom abort() function. Now we have to hope
the compiler can figure out that our abort() wrapper doesn't return, and we
probably have to annotate our abort() to help the compiler along.

Another example that always comes to mind is where the compiler may
replace an indirect call via a NULL function pointer with a direct call to a
function f() that is never actually assigned to the function pointer, because
it detected that f() is the only possible target of the pointer and calling a
NULL function pointer is also UB.
 
> We don't do this kind of analysis in GHC at the moment, and we don't 
> have quite so much undefined behaviour floating around. But I can 
> imagine similar issues might arise. I mean, we most definitely assume 
> that the result of `unsafeCoerce#` is a value of the claimed type - 
> what else can you do? I suppose I'm not really clear on what 
> specifically it would mean to adopt "illegal but unchecked" as the 
> policy for undefined behaviour. Does it mean the compiler can't assume 
> anything about the result of an operation that has any undefined 
> behaviour?

That's a fair point. I'm not entirely clear on where to draw the line either,
but maybe respecting causality would be a good place to start. So it's fine
for us to assume that operations that have UB complete successfully, and
to assume the inputs satisfy the operation's contract from that point on,
but maybe we should avoid propagating those assumptions back before
the call-site that may invoke UB. But then what do we do about loops? It
seems we would either have to special case the first iteration or block
optimizations in the first section of the loop on every iteration.. Both
options sound terrible..

From eric at seidel.io  Thu Dec  3 14:53:29 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Dec 2020 09:53:29 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
Message-ID: <a55d4b49-a3f7-44dc-9355-1455648785c9@www.fastmail.com>

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.

From trupill at gmail.com  Thu Dec  3 16:15:14 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 3 Dec 2020 08:15:14 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAH6fHQnnFcCHZWtv3MtsW8aXb=FSBhph-C0bM6Lq+_yukeyNyQ@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
 <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>
 <CAH6fHQnnFcCHZWtv3MtsW8aXb=FSBhph-C0bM6Lq+_yukeyNyQ@mail.gmail.com>
Message-ID: <CAHnFXOv5pf4P8iP71zeenprdgq20PPk6MODAge4dGiM_bewO_g@mail.gmail.com>

 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/06490c38/attachment-0001.html>

From rae at richarde.dev  Thu Dec  3 16:32:16 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Dec 2020 16:32:16 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
Message-ID: <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>



> On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/d04225a5/attachment.html>

From rae at richarde.dev  Thu Dec  3 16:40:28 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Dec 2020 16:40:28 +0000
Subject: [ghc-steering-committee] a plea for PolyKinds
Message-ID: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>

Hi all,

I'd like to make a small plea for PolyKinds.

* Haskell is more Haskelly with PolyKinds than without. That is, a key attribute of Haskell is its let-generalization. Yet, oddly, Haskell by default does not generalize its kinds. It should. Here is a motivating example:

> data App f a = App (f a)

With PolyKinds, App gets the kind (k -> Type) -> k -> Type. Without PolyKinds, GHC has to use defaulting to get (Type -> Type) -> Type -> Type, which might not work at certain use sites.

* PolyKinds is backward compatible, except in obscure cases when a PolyKinds module is imported by a NoPolyKinds module.

* Supporting NoPolyKinds is difficult within GHC, and I've been waiting for the right time to propose removing support for it. PolyKinds is conceptually *simpler* than NoPolyKinds, as it doesn't require an awkward defaulting step.

Vote for PolyKinds!

Thanks,
Richard

From rae at richarde.dev  Thu Dec  3 16:48:17 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Dec 2020 16:48:17 +0000
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
Message-ID: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>

Hi all,

I'd like to make a small plea against ScopedTypeVariables.

* First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.

* But I very much dislike the way it brings variables into scope from `forall`s. When I write

> f :: forall a. a -> a
> f x = (x :: a)

I find it very odd that `a` is brought into scope in the body of f. Compare to

> f :: (forall a. a -> a)
> f x = (x :: a)

where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.

* Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.

* I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523, which re-slices this cake.

Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.

Thanks,
Richard

From simonpj at microsoft.com  Thu Dec  3 16:58:20 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2020 16:58:20 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 03 December 2020 16:32
To: Alejandro Serrano Mena <trupill at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status




On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/95058c0b/attachment-0001.html>

From iavor.diatchki at gmail.com  Thu Dec  3 16:58:41 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 08:58:41 -0800
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <4f232602-37cf-45c2-930d-841d60fb2d4c@www.fastmail.com>
References: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
 <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>
 <CANsrgPL3fqRpojg0ej-Rt1O0zb_0dL2uDG9aWTkFOz2hh9RXuw@mail.gmail.com>
 <4f232602-37cf-45c2-930d-841d60fb2d4c@www.fastmail.com>
Message-ID: <CAGK9nupYMrtb83eXfFLNYds8PV5ia+bEgG53f0h-FsyN02NLWw@mail.gmail.com>

I don't think we should worry about trying to provide sane behavior for
when people violate stated assumptions---doing so makes the compiler's work
harder, and encourages people to violate the assumptions.  It is important
to document clearly what the assumptions are, of course.

-Iavor


On Thu, Dec 3, 2020 at 6:52 AM Eric Seidel <eric at seidel.io> wrote:

> On Thu, Dec 3, 2020, at 05:29, Simon Marlow wrote:
> > My understanding of what happened in C compilers is that the optimisers
> > want to do some dataflow analysis to determine the ranges of values
> > that variables can take, in order to eliminate unnecessary conditionals
> > and so forth. These analyses are severely crippled if you can't assume
> > the absence of undefined behaviour in C/C++, because most arithmetic
> > operations have undefined behaviour: overflow is undefined, for example.
>
> Right, I think what leads to the surprising behavior in C/C++ is that
> compilers
> sometimes use the results of the dataflow analysis in a manner that
> violates
> causality.
>
> For example, removing a NULL check because later on the pointer
> is dereferenced unconditionally. I don't think anyone would complain about
> the compiler removing NULL checks *after* the dereference, but doing so
> before is a bit unsettling. Suppose the NULL check the compiler cleverly
> elided was meant to call into a custom abort() function. Now we have to
> hope
> the compiler can figure out that our abort() wrapper doesn't return, and we
> probably have to annotate our abort() to help the compiler along.
>
> Another example that always comes to mind is where the compiler may
> replace an indirect call via a NULL function pointer with a direct call to
> a
> function f() that is never actually assigned to the function pointer,
> because
> it detected that f() is the only possible target of the pointer and
> calling a
> NULL function pointer is also UB.
>
> > We don't do this kind of analysis in GHC at the moment, and we don't
> > have quite so much undefined behaviour floating around. But I can
> > imagine similar issues might arise. I mean, we most definitely assume
> > that the result of `unsafeCoerce#` is a value of the claimed type -
> > what else can you do? I suppose I'm not really clear on what
> > specifically it would mean to adopt "illegal but unchecked" as the
> > policy for undefined behaviour. Does it mean the compiler can't assume
> > anything about the result of an operation that has any undefined
> > behaviour?
>
> That's a fair point. I'm not entirely clear on where to draw the line
> either,
> but maybe respecting causality would be a good place to start. So it's fine
> for us to assume that operations that have UB complete successfully, and
> to assume the inputs satisfy the operation's contract from that point on,
> but maybe we should avoid propagating those assumptions back before
> the call-site that may invoke UB. But then what do we do about loops? It
> seems we would either have to special case the first iteration or block
> optimizations in the first section of the loop on every iteration.. Both
> options sound terrible..
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/82870022/attachment.html>

From eric at seidel.io  Thu Dec  3 17:06:10 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Dec 2020 12:06:10 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23313=3A_Delimi?=
 =?utf-8?q?ted_continuation_primops=2C_Shepherd=3A_Simon_Marlow?=
In-Reply-To: <CAGK9nupYMrtb83eXfFLNYds8PV5ia+bEgG53f0h-FsyN02NLWw@mail.gmail.com>
References: <CANsrgP+sa9Mxo-buPGFcmTobBR-C3sNJUOo-qVN05Ytrm4yetQ@mail.gmail.com>
 <3D134EDB-AF61-4829-BCB4-83BD4D2C59BB@seidel.io>
 <CANsrgPL3fqRpojg0ej-Rt1O0zb_0dL2uDG9aWTkFOz2hh9RXuw@mail.gmail.com>
 <4f232602-37cf-45c2-930d-841d60fb2d4c@www.fastmail.com>
 <CAGK9nupYMrtb83eXfFLNYds8PV5ia+bEgG53f0h-FsyN02NLWw@mail.gmail.com>
Message-ID: <32548d41-5b17-4f69-b600-d165df5113f6@www.fastmail.com>

Yeah, I think I convinced myself while writing my last reply that it's not worth
the trouble.

On Thu, Dec 3, 2020, at 11:58, Iavor Diatchki wrote:
> I don't think we should worry about trying to provide sane behavior for 
> when people violate stated assumptions---doing so makes the compiler's 
> work harder, and encourages people to violate the assumptions.  It is 
> important to document clearly what the assumptions are, of course.
> 
> -Iavor
> 
> 
> On Thu, Dec 3, 2020 at 6:52 AM Eric Seidel <eric at seidel.io> wrote:
> > On Thu, Dec 3, 2020, at 05:29, Simon Marlow wrote:
> > > My understanding of what happened in C compilers is that the optimisers 
> > > want to do some dataflow analysis to determine the ranges of values 
> > > that variables can take, in order to eliminate unnecessary conditionals 
> > > and so forth. These analyses are severely crippled if you can't assume 
> > > the absence of undefined behaviour in C/C++, because most arithmetic 
> > > operations have undefined behaviour: overflow is undefined, for example.
> > 
> > Right, I think what leads to the surprising behavior in C/C++ is that compilers
> > sometimes use the results of the dataflow analysis in a manner that violates
> > causality.
> > 
> > For example, removing a NULL check because later on the pointer
> > is dereferenced unconditionally. I don't think anyone would complain about
> > the compiler removing NULL checks *after* the dereference, but doing so
> > before is a bit unsettling. Suppose the NULL check the compiler cleverly
> > elided was meant to call into a custom abort() function. Now we have to hope
> > the compiler can figure out that our abort() wrapper doesn't return, and we
> > probably have to annotate our abort() to help the compiler along.
> > 
> > Another example that always comes to mind is where the compiler may
> > replace an indirect call via a NULL function pointer with a direct call to a
> > function f() that is never actually assigned to the function pointer, because
> > it detected that f() is the only possible target of the pointer and calling a
> > NULL function pointer is also UB.
> > 
> > > We don't do this kind of analysis in GHC at the moment, and we don't 
> > > have quite so much undefined behaviour floating around. But I can 
> > > imagine similar issues might arise. I mean, we most definitely assume 
> > > that the result of `unsafeCoerce#` is a value of the claimed type - 
> > > what else can you do? I suppose I'm not really clear on what 
> > > specifically it would mean to adopt "illegal but unchecked" as the 
> > > policy for undefined behaviour. Does it mean the compiler can't assume 
> > > anything about the result of an operation that has any undefined 
> > > behaviour?
> > 
> > That's a fair point. I'm not entirely clear on where to draw the line either,
> > but maybe respecting causality would be a good place to start. So it's fine
> > for us to assume that operations that have UB complete successfully, and
> > to assume the inputs satisfy the operation's contract from that point on,
> > but maybe we should avoid propagating those assumptions back before
> > the call-site that may invoke UB. But then what do we do about loops? It
> > seems we would either have to special case the first iteration or block
> > optimizations in the first section of the loop on every iteration.. Both
> > options sound terrible..
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From iavor.diatchki at gmail.com  Thu Dec  3 17:20:46 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 09:20:46 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nur_vm7Z7ApBZD06WuO64xfamn2sFoQqTrAgHhm47dJuUw@mail.gmail.com>

Hello,

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.

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.

-Iavor








On Thu, Dec 3, 2020 at 8:58 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> 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 <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 03 December 2020 16:32
> *To:* Alejandro Serrano Mena <trupill at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] #380 GHC2021: Current status
>
>
>
>
>
>
>
> On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at 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.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/d92dd3a7/attachment-0001.html>

From rae at richarde.dev  Thu Dec  3 17:30:52 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Dec 2020 17:30:52 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>



> On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones <simonpj at microsoft.com> 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-ghc-extensions.rst#criteria.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/8fe80d18/attachment.html>

From mail at joachim-breitner.de  Thu Dec  3 17:46:00 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 18:46:00 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting tweaks?
In-Reply-To: <CAGK9nur_vm7Z7ApBZD06WuO64xfamn2sFoQqTrAgHhm47dJuUw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nur_vm7Z7ApBZD06WuO64xfamn2sFoQqTrAgHhm47dJuUw@mail.gmail.com>
Message-ID: <f447addc11afd0ad266bb895c78192035b4ff95c.camel@joachim-breitner.de>

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



From mail at joachim-breitner.de  Thu Dec  3 17:47:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 18:47:59 +0100
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
Message-ID: <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> Vote for PolyKinds!

convinced.

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



From iavor.diatchki at gmail.com  Thu Dec  3 17:51:25 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 09:51:25 -0800
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>

I would totally support that if PolyKinds was implemented without requiring
TypeInType, but with the current design for me this is a solid `no`.


On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> > Vote for PolyKinds!
>
> convinced.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/dfd12a7b/attachment.html>

From simonpj at microsoft.com  Thu Dec  3 17:53:56 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2020 17:53:56 +0000
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
 <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
Message-ID: <VI1PR83MB0222C3805B0FD695FD6307BFADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I would totally support that if PolyKinds was implemented without requiring TypeInType, but with the current design for me this is a solid `no`.
Maybe you can say why?  Solid sounds… solid.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 03 December 2020 17:51
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] a plea for PolyKinds

I would totally support that if PolyKinds was implemented without requiring TypeInType, but with the current design for me this is a solid `no`.


On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> Vote for PolyKinds!

convinced.

Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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%7Ca7e57ca1aaa04682c10e08d897b416c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426147016852738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5BRa1m9VmGYrpfPd%2BCU6kuR2mRMwnGHL56rKmYDevag%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7Ca7e57ca1aaa04682c10e08d897b416c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426147016862731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ajZ4O2lU0DtkM63hKuG6skeitXdkFtYZ6xiklAKzEms%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/b54e309a/attachment-0001.html>

From iavor.diatchki at gmail.com  Thu Dec  3 17:54:17 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 09:54:17 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Voting tweaks?
In-Reply-To: <f447addc11afd0ad266bb895c78192035b4ff95c.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nur_vm7Z7ApBZD06WuO64xfamn2sFoQqTrAgHhm47dJuUw@mail.gmail.com>
 <f447addc11afd0ad266bb895c78192035b4ff95c.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqp177-sAD9SJArH2BWDEED3OcUa67GaULegF=mo5U2VQ@mail.gmail.com>

OK, cool, I might play around with it, I'll post an update if I get
something working.

On Thu, Dec 3, 2020 at 9:46 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/65eca653/attachment.html>

From iavor.diatchki at gmail.com  Thu Dec  3 18:36:08 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 10:36:08 -0800
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <VI1PR83MB0222C3805B0FD695FD6307BFADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
 <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
 <VI1PR83MB0222C3805B0FD695FD6307BFADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuon2Awji5Q9zcmWvhzATEHAhWOj+g3KRAOwUtgqv74k=g@mail.gmail.com>

I find the distinction between types and kinds helps me understand programs
better.

On Thu, Dec 3, 2020 at 9:53 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I would totally support that if PolyKinds was implemented without
> requiring TypeInType, but with the current design for me this is a solid
> `no`.
>
> Maybe you can say why?  Solid sounds… solid.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 03 December 2020 17:51
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] a plea for PolyKinds
>
>
>
> I would totally support that if PolyKinds was implemented without
> requiring TypeInType, but with the current design for me this is a solid
> `no`.
>
>
>
>
>
> On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> > Vote for PolyKinds!
>
> convinced.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at 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%7Ca7e57ca1aaa04682c10e08d897b416c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426147016852738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5BRa1m9VmGYrpfPd%2BCU6kuR2mRMwnGHL56rKmYDevag%3D&reserved=0>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7Ca7e57ca1aaa04682c10e08d897b416c6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426147016862731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ajZ4O2lU0DtkM63hKuG6skeitXdkFtYZ6xiklAKzEms%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/dc657b62/attachment.html>

From trupill at gmail.com  Thu Dec  3 19:50:42 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 3 Dec 2020 20:50:42 +0100
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
 <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
Message-ID: <CAHnFXOsTABSgJnNbOsVCBAbBFmoqR6GSr604R0=1hvmT9jwbXQ@mail.gmail.com>

But PolyKinds does not require TypeInType, according to the docs [
https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PolyKinds]
it is in fact the other way around: TypeInType implies PolyKinds. Of
course, the fact that kinds and types are unified may leak somehow, but I
have a hard time figuring out an example of such.

El jue, 3 dic 2020 a las 18:51, Iavor Diatchki (<iavor.diatchki at gmail.com>)
escribió:

> I would totally support that if PolyKinds was implemented without
> requiring TypeInType, but with the current design for me this is a solid
> `no`.
>
>
> On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
>> > Vote for PolyKinds!
>>
>> convinced.
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/f7006956/attachment.html>

From iavor.diatchki at gmail.com  Thu Dec  3 19:53:28 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Dec 2020 11:53:28 -0800
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <CAHnFXOsTABSgJnNbOsVCBAbBFmoqR6GSr604R0=1hvmT9jwbXQ@mail.gmail.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
 <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
 <CAHnFXOsTABSgJnNbOsVCBAbBFmoqR6GSr604R0=1hvmT9jwbXQ@mail.gmail.com>
Message-ID: <CAGK9nurWuhRopU3ePKqRgifym5zLHhnK_QjHQ6tZG6ONOhWbMA@mail.gmail.com>

Oh?  Perhaps I am confused, if we can have PolyKinds without TypeInType,
I'd be happy to change my vote.  My understanding was that basically
`TypeInType` got renamed to  `PolyKinds` but I might be confused.

-Iavor

On Thu, Dec 3, 2020 at 11:50 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> But PolyKinds does not require TypeInType, according to the docs [
> https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PolyKinds]
> it is in fact the other way around: TypeInType implies PolyKinds. Of
> course, the fact that kinds and types are unified may leak somehow, but I
> have a hard time figuring out an example of such.
>
> El jue, 3 dic 2020 a las 18:51, Iavor Diatchki (<iavor.diatchki at gmail.com>)
> escribió:
>
>> I would totally support that if PolyKinds was implemented without
>> requiring TypeInType, but with the current design for me this is a solid
>> `no`.
>>
>>
>> On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
>>> > Vote for PolyKinds!
>>>
>>> convinced.
>>>
>>> Cheers,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/a96498fe/attachment-0001.html>

From trupill at gmail.com  Thu Dec  3 20:06:11 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 3 Dec 2020 21:06:11 +0100
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOv+CSzEKQcb2_n-eKfih0cWZ53c1gaJviBn6gpC17+N1Q@mail.gmail.com>

Whereas I agree that ScopedTypeVariables may not be ideal in its current
incarnation, I think we should include this one for a few reasons.

* It's used a lot, in fact it's one of the most popular extensions in the
survey, while still being not that contentious. I think almost everybody
enables it liberally.

* It doesn't do harm unless you add the explicit 'forall' in the type
signatures.

* Right now, there's no other way to bring type variables into scope! It
would be really weird if GHC2021 would have TypeApplications, but I need to
enable an extension to refer to variables in scope.

El jue, 3 dic 2020 a las 17:48, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> Hi all,
>
> I'd like to make a small plea against ScopedTypeVariables.
>
> * First off, I love (most of) ScopedTypeVariables, and enable it
> liberally. It is a safe extension.
>
> * But I very much dislike the way it brings variables into scope from
> `forall`s. When I write
>
> > f :: forall a. a -> a
> > f x = (x :: a)
>
> I find it very odd that `a` is brought into scope in the body of f.
> Compare to
>
> > f :: (forall a. a -> a)
> > f x = (x :: a)
>
> where I have added parentheses to the type of f. Now `a` is not in scope
> in the body of f. That's bizarre.
>
> * Note that type signatures and function definitions can be arbitrarily
> separated in a file. Some programmers indeed prefer to do this, so that
> type signatures can all be in one place, forming an interface to the file.
> (I've even seen header files, included via CPP!) I'm not necessarily
> advocating for that style, but I can't quite say it's absurd. Our ML
> friends do this reflexively.
>
> * I'm hoping ScopedTypeVariables will lose this feature in the future.
> I've been meaning to propose such for some time. See
> https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523,
> which re-slices this cake.
>
> Thus, given the potential for change in the future, and some drawbacks of
> the extension as it currently stands, I think we should not enable it by
> default, making change harder in the future.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/846bc766/attachment.html>

From trupill at gmail.com  Thu Dec  3 20:16:44 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 3 Dec 2020 12:16:44 -0800
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>

 Dear Committee,

Richard has requested for us to consider the new version of this proposal.
As opposed to the previous version, this one is only about reserving syntax
for “modifiers”, which at the beginning would be used for things like
linearity or matchability of arrows.

I think this is a good proposal, and one which would save us from
re-considering syntax for every possible extension (and if linearity
appears before the arrow and matchability after it, where would a future
dimension go?). Thus I keep recommending acceptance on this new incarnation.

Regards,
Alejandro


On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:

> To my surprise, I found myself leaning against. So I updated and
> simplified the proposal to remove Modifier. This makes modifiers a bit more
> magical, but more likely to actually work in practice. The type inference
> story previously may have been intractable.
>
> I've requested that the committee consider the updates in parallel with
> community feedback.
>
> Thanks,
> Richard
>
> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> After some discussion in the GitHub thread, changes are going to arrive to
> the proposal. I think the best is to send the proposal back to the “Needs
> revision” state.
>
> Regards,
> Alejandro
>
> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>
>> I left a few comments and questions on the PR itself, but I'm leaning
>> towards rejecting the proposal in its current form as well. This doesn't
>> (yet) feel like a generic mechanism, in particular because the only
>> modifier that has been specified would be deeply wired into GHC itself.
>>
>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>
>> Hi,
>>
>>
>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>
>> Mena:
>>
>> > Dear all,
>>
>> > This proposal suggests adding syntax for a general notion of
>>
>> > modifiers, like the ones we’ve been talking about lately affecting
>>
>> > linearity or matchability of arrows. For example, if linear types and
>>
>> > unsaturated families are accepted as they stand, we would have `Int
>>
>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>
>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>
>> >
>>
>> > Since the amount of modifiers is likely to increase in the future, I
>>
>> > think it’s a great idea to agree and reserve such syntax, instead of
>>
>> > coming up with different ways on each proposal. I thus recommend
>>
>> > acceptance of this proposal.
>>
>> >
>>
>> > The proposal itself:
>>
>> > (1) introduces syntax for modifiers in types and defines how to
>>
>> > type/kind check them,
>>
>> > (2) reserved such syntax for other uses in declarations and terms.
>>
>> >
>>
>> > I think the proposal still has its merits only with (1), even though
>>
>> > I lean towards accepting both parts of it.
>>
>>
>> I like the idea of reserving syntax here, but parts of the proposal
>>
>> smell a bit like premature generalization to me. Are we confident that
>>
>> all annotations we eventually would like to use with this feature can
>>
>> be expressed as types of a kind that is an instance of Modifier? Or
>>
>> should we reserve the ability to have annotations that don't fit that
>>
>> model?
>>
>>
>> Would we ever have annotation that may affect phases earlier than than
>>
>> typechecking? What if we want to use (%type e) and (%data e) to help
>>
>> with the SingleNamepace issues? Look like useful annotations to me, but
>>
>> I am not sure if they fit the framework proposed here.
>>
>>
>> The fact that we special-case %1 supports that.
>>
>>
>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>
>> isn't that indication that using the type system to model the various
>>
>> modifiers might be the wrong tool?
>>
>>
>> I wonder if there is a way where the %(…) on it’s own only reserve
>>
>> syntax, and the various uses of that syntax can be disambiguated
>>
>> _statically_ based on the content of ….
>>
>>
>> Not great syntax, because not concise, enough, but morally I’d feel
>>
>> more at ease with
>>
>>
>>   Int %(multiplicity Many) -> Int
>>
>>   Int %(multiplicity 1) -> Int
>>
>>   Int %(multiplicity m) -> Int
>>
>>
>> where multiplicity is a modifier keyword, to express the existing
>>
>> features (including implicit generalization of m). Then we can extend
>>
>> this to
>>
>>
>>   Int %oneShot -> Int
>>
>>
>> and
>>
>>
>>   Int %(matchability M) -> Int
>>
>>
>> and maybe even
>>
>>
>>   foo (%type [a]) -- where foo :: forall a -> ()
>>
>>
>> which is a modifier that
>>
>>
>>
>> So at the moment, I am inclined to reject this proposal, until I am
>>
>> convinced that we are not painting ourselves into a “all modifiers are
>>
>> types of special kinds and that’s all the syntax and behaviour we ever
>>
>> need” corner.
>>
>>
>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>
>> should we also be able to annotate other infix operators, i.e.
>>
>>
>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>
>>   infixexp ::= lexp {modifier} qop infixexp
>>
>>
>>
>>
>> Cheers,
>>
>> Joachim
>>
>>
>>
>> --
>>
>> Joachim Breitner
>>
>>   mail at joachim-breitner.de
>>
>>   http://www.joachim-breitner.de/
>>
>>
>>
>> _______________________________________________
>>
>> ghc-steering-committee mailing list
>>
>> ghc-steering-committee at haskell.org
>>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/964f4dc3/attachment-0001.html>

From eric at seidel.io  Thu Dec  3 20:16:51 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Dec 2020 15:16:51 -0500
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <CAHnFXOv+CSzEKQcb2_n-eKfih0cWZ53c1gaJviBn6gpC17+N1Q@mail.gmail.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
 <CAHnFXOv+CSzEKQcb2_n-eKfih0cWZ53c1gaJviBn6gpC17+N1Q@mail.gmail.com>
Message-ID: <cc65d168-8336-46c4-b0c2-a2c6dcc3fee1@www.fastmail.com>

Although I have not yet submitted my votes yet, I do plan to vote for
including ScopedTypeVariables, even though I also have some issues
with it. Richard complains that `forall` brings type variables into scope
at the term-level; I'm annoyed that I have to write the `forall` in the
first place, I'd prefer to have all type variables brought into scope.

But these quibbles don't matter. ScopedTypeVariables is a supremely
useful extension even in its current state, and we should enable it.
If we come up with a different, better design for ScopedTypeVariables
in the future, we can

1. give it a new name
2. in GHC202X replace ScopedTypeVariables with the new extension
3. (slowly) deprecate ScopedTypeVariables

Note that step 2 is non-breaking because people have to opt into
the new language standard, so it actually makes these kinds of
changes easier. That's one of the major draws of the GHC20XX
idea!

On Thu, Dec 3, 2020, at 15:06, Alejandro Serrano Mena wrote:
> Whereas I agree that ScopedTypeVariables may not be ideal in its 
> current incarnation, I think we should include this one for a few 
> reasons.
> 
> * It's used a lot, in fact it's one of the most popular extensions in 
> the survey, while still being not that contentious. I think almost 
> everybody enables it liberally.
> 
> * It doesn't do harm unless you add the explicit 'forall' in the type 
> signatures.
> 
> * Right now, there's no other way to bring type variables into scope! 
> It would be really weird if GHC2021 would have TypeApplications, but I 
> need to enable an extension to refer to variables in scope.
> 
> El jue, 3 dic 2020 a las 17:48, Richard Eisenberg (<rae at richarde.dev>) escribió:
> > Hi all,
> > 
> > I'd like to make a small plea against ScopedTypeVariables.
> > 
> > * First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.
> > 
> > * But I very much dislike the way it brings variables into scope from `forall`s. When I write
> > 
> > > f :: forall a. a -> a
> > > f x = (x :: a)
> > 
> > I find it very odd that `a` is brought into scope in the body of f. Compare to
> > 
> > > f :: (forall a. a -> a)
> > > f x = (x :: a)
> > 
> > where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.
> > 
> > * Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.
> > 
> > * I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523, which re-slices this cake.
> > 
> > Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.
> > 
> > Thanks,
> > Richard
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From cgibbard at gmail.com  Thu Dec  3 20:19:40 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Thu, 3 Dec 2020 15:19:40 -0500
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
Message-ID: <CAF3RzK8JYZQAJPf0FgU-sk=pgCcdRQyOTTnE86keCqySHoD73g@mail.gmail.com>

I agree with Richard as well on this point. The error messages GHC
reports can be practically incomprehensible and even misleading when
PolyKinds is accidentally turned off in a module that imports and
attempts to use poly-kinded things. I could probably drum up an
example if people want (I've run into this problem several times, but
don't have one immediately on hand.)

If it were just switched on by default, I'd feel a lot better about
the extension, because I wouldn't have to worry that consumers of any
poly-kinded things I wrote had to be aware of these stumbling blocks.
Of course, if GHC could get better at suggesting that users should
turn PolyKinds on in the cases where it's an issue, that would also be
great, but I'm not quite sure how to approach that either.


 - Cale

On Thu, 3 Dec 2020 at 12:48, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Hi,
>
> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> > Vote for PolyKinds!
>
> convinced.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From mail at joachim-breitner.de  Thu Dec  3 21:50:03 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 03 Dec 2020 22:50:03 +0100
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
Message-ID: <bb47e0a0ca58b7a28a29b695acfe2f247ffa4bd9.camel@joachim-breitner.de>

Hi,

thanks, that’s better. It is still a pretty generic bet on the future
(here is a general syntax that we now hope will be useful for multiple
things that we don’t even know about yet). But that’s fine, especially
if the bet wins.

Do we actually need a dedicated language extension for it, though? Why
not make this proposal “from now on, LinearHaskell uses this syntax,
and we plan to use compatible syntax for other extensions”? (this is
all there effectively really is, isn’t it? a tweak to LinearHaskell,
and a pledge to follow this pattern)


Cheers,
Joachim

Am Donnerstag, den 03.12.2020, 12:16 -0800 schrieb Alejandro Serrano
Mena:
> Dear Committee,
> 
> Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
> 
> I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
> 
> Regards,
> Alejandro
> 
> 
> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
> > To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
> > 
> > I've requested that the committee consider the updates in parallel with community feedback.
> > 
> > Thanks,
> > Richard
> > 
> > > On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > > 
> > > After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
> > > 
> > > Regards,
> > > Alejandro
> > > 
> > > On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
> > > > I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
> > > > 
> > > > On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
> > > > > Hi,
> > > > > Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
> > > > > Mena:
> > > > > > Dear all,
> > > > > > This proposal suggests adding syntax for a general notion of
> > > > > > modifiers, like the ones we’ve been talking about lately affecting
> > > > > > linearity or matchability of arrows. For example, if linear types and
> > > > > > unsaturated families are accepted as they stand, we would have `Int
> > > > > > #1 -> @U Bool` (or something like that), whereas with this proposal
> > > > > > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
> > > > > > 
> > > > > > Since the amount of modifiers is likely to increase in the future, I
> > > > > > think it’s a great idea to agree and reserve such syntax, instead of
> > > > > > coming up with different ways on each proposal. I thus recommend
> > > > > > acceptance of this proposal.
> > > > > > 
> > > > > > The proposal itself:
> > > > > > (1) introduces syntax for modifiers in types and defines how to
> > > > > > type/kind check them,
> > > > > > (2) reserved such syntax for other uses in declarations and terms.
> > > > > > 
> > > > > > I think the proposal still has its merits only with (1), even though
> > > > > > I lean towards accepting both parts of it.
> > > > > I like the idea of reserving syntax here, but parts of the proposal
> > > > > smell a bit like premature generalization to me. Are we confident that
> > > > > all annotations we eventually would like to use with this feature can
> > > > > be expressed as types of a kind that is an instance of Modifier? Or
> > > > > should we reserve the ability to have annotations that don't fit that
> > > > > model?
> > > > > Would we ever have annotation that may affect phases earlier than than
> > > > > typechecking? What if we want to use (%type e) and (%data e) to help
> > > > > with the SingleNamepace issues? Look like useful annotations to me, but
> > > > > I am not sure if they fit the framework proposed here.
> > > > > The fact that we special-case %1 supports that.
> > > > > The proposal explicitly has to state “No modifier polymorphism!”. But
> > > > > isn't that indication that using the type system to model the various
> > > > > modifiers might be the wrong tool?
> > > > > I wonder if there is a way where the %(…) on it’s own only reserve
> > > > > syntax, and the various uses of that syntax can be disambiguated
> > > > > _statically_ based on the content of …. 
> > > > > Not great syntax, because not concise, enough, but morally I’d feel
> > > > > more at ease with
> > > > >   Int %(multiplicity Many) -> Int
> > > > >   Int %(multiplicity 1) -> Int
> > > > >   Int %(multiplicity m) -> Int
> > > > > where multiplicity is a modifier keyword, to express the existing
> > > > > features (including implicit generalization of m). Then we can extend
> > > > > this to
> > > > >   Int %oneShot -> Int
> > > > > and
> > > > >   Int %(matchability M) -> Int
> > > > > and maybe even
> > > > >   foo (%type [a]) -- where foo :: forall a -> ()
> > > > > which is a modifier that 
> > > > > So at the moment, I am inclined to reject this proposal, until I am
> > > > > convinced that we are not painting ourselves into a “all modifiers are
> > > > > types of special kinds and that’s all the syntax and behaviour we ever
> > > > > need” corner.
> > > > > Minor detail: If we can annotate infix use of the (->) “type operator”,
> > > > > should we also be able to annotate other infix operators, i.e.
> > > > >   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) 
> > > > >   infixexp ::= lexp {modifier} qop infixexp
> > > > > Cheers,
> > > > > Joachim
> > > > > -- 
> > > > > Joachim Breitner
> > > > >   mail at joachim-breitner.de
> > > > >   http://www.joachim-breitner.de/
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Thu Dec  3 21:50:20 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Dec 2020 21:50:20 +0000
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <CAGK9nurWuhRopU3ePKqRgifym5zLHhnK_QjHQ6tZG6ONOhWbMA@mail.gmail.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <931be767b10fadd69217b57ec7413528f78a0e62.camel@joachim-breitner.de>
 <CAGK9nuqSbx2frdMHWoBKg028KermkzdBG=akNb7z9BDFj4WSyQ@mail.gmail.com>
 <CAHnFXOsTABSgJnNbOsVCBAbBFmoqR6GSr604R0=1hvmT9jwbXQ@mail.gmail.com>
 <CAGK9nurWuhRopU3ePKqRgifym5zLHhnK_QjHQ6tZG6ONOhWbMA@mail.gmail.com>
Message-ID: <010f01762a95ac64-fd1f26f3-1404-424f-a653-adb59b1c81c9-000000@us-east-2.amazonses.com>

The truth is that (Type :: Type) is true no matter what (though you'd need KindSignatures for GHC to accept that). The features that were previously -XTypeInType have been moved into -XPolyKinds (and a few in -XDataKinds), because there seemed to be very little reason to keep the two extensions separate. PolyKinds essentially allows two things: it allows users to write variables and other constructs (like `forall`) in kinds, and it allows GHC to do kind-generalization. But nothing about -XPolyKinds really changes the relationship between types and kinds.

Richard

> On Dec 3, 2020, at 2:53 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Oh?  Perhaps I am confused, if we can have PolyKinds without TypeInType, I'd be happy to change my vote.  My understanding was that basically `TypeInType` got renamed to  `PolyKinds` but I might be confused.
> 
> -Iavor
> 
> On Thu, Dec 3, 2020 at 11:50 AM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> But PolyKinds does not require TypeInType, according to the docs [https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PolyKinds <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PolyKinds>] it is in fact the other way around: TypeInType implies PolyKinds. Of course, the fact that kinds and types are unified may leak somehow, but I have a hard time figuring out an example of such.
> 
> El jue, 3 dic 2020 a las 18:51, Iavor Diatchki (<iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>) escribió:
> I would totally support that if PolyKinds was implemented without requiring TypeInType, but with the current design for me this is a solid `no`.
> 
> 
> On Thu, Dec 3, 2020 at 9:48 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Donnerstag, den 03.12.2020, 16:40 +0000 schrieb Richard Eisenberg:
> > Vote for PolyKinds!
> 
> convinced.
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/eb63c42c/attachment-0001.html>

From eric at seidel.io  Fri Dec  4 02:19:58 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Dec 2020 21:19:58 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAHnFXOv5pf4P8iP71zeenprdgq20PPk6MODAge4dGiM_bewO_g@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
 <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>
 <CAH6fHQnnFcCHZWtv3MtsW8aXb=FSBhph-C0bM6Lq+_yukeyNyQ@mail.gmail.com>
 <CAHnFXOv5pf4P8iP71zeenprdgq20PPk6MODAge4dGiM_bewO_g@mail.gmail.com>
Message-ID: <cd5c5bee-56a6-4d5c-a474-7f8e4610eb82@www.fastmail.com>

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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From arnaud.spiwack at tweag.io  Fri Dec  4 07:10:44 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 08:10:44 +0100
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass
In-Reply-To: <CAHnFXOt6XvjVxYerF-f+PbxiikNzwURW+XBm4Jqd_7g2DOcKaw@mail.gmail.com>
References: <CAHnFXOsTLzP_tPkQVbZ33=CPi=Fq9KHdByusc2js51NcbDSJfA@mail.gmail.com>
 <VI1PR83MB0222E264DBEC1BE7A223940DADF41@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <9d05323d98c617c1d3abbb1428952428751b9cb7.camel@joachim-breitner.de>
 <CAHnFXOt6XvjVxYerF-f+PbxiikNzwURW+XBm4Jqd_7g2DOcKaw@mail.gmail.com>
Message-ID: <CAH6fHQ=Fnr3N9Qd3zkySY5sapeW5-O9yKep+DDMX9tLRgw01HA@mail.gmail.com>

On Tue, Dec 1, 2020 at 9:47 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Thanks for the illuminating discussion! I’ve been convinced that we should
> move away from DeriveAnyClass, and provide and start using ‘via
> Generically’ instead. Which happily also gets rid of DefaultSignatures,
> which I never liked due to the intimate bundling with the class
> declaration.
>

This is a statement that I can't necessarily get behind. I've got enough
experience with DerivingVia to say that it is a pretty esoteric extension.
The error messages are pretty bad, and it's easy to get bitten by the lack
of higher-order roles (see also: roles). But more importantly, it's simply
difficult to grasp how to use this extension, it's its own language inside
the language. DerivingVia is likely to remain very advanced Haskell for
quite a while. Whereas DeriveAnyClass is rather simple, even if fraught
with subtle traps like we've discussed here; hence probably not worth
including in our first round of default where we rather want to stay
conservative, until we have fewer extensions to consider and we can
scrutinise them more carefully.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/98980825/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 08:18:29 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 09:18:29 +0100
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQnz_wGmbP77z_MVrGNu0P+12DEHQEG9MiCrihfPhyhB4w@mail.gmail.com>

On Thu, Dec 3, 2020 at 5:40 PM Richard Eisenberg <rae at richarde.dev> wrote:

> > data App f a = App (f a)
>
> With PolyKinds, App gets the kind (k -> Type) -> k -> Type. Without
> PolyKinds, GHC has to use defaulting to get (Type -> Type) -> Type -> Type,
> which might not work at certain use sites.
>

You know how I dislike this automatic kind generalisation. This is not
going to win me over :-p .  I still think that the polymorphism inference
of PolyKind was a mistake. That being said, it's something that we have
committed to. It's going to be quite hard to change any time soon.


> * Supporting NoPolyKinds is difficult within GHC, and I've been waiting
> for the right time to propose removing support for it. PolyKinds is
> conceptually *simpler* than NoPolyKinds, as it doesn't require an awkward
> defaulting step.
>

On the other hand, I'd say that this is a rather strong argument. Who else
wants to remove `NoPolyKinds`? Simon PJ, what do you think?

Is it even possible while still supporting Haskell2010?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/a6220f1d/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 08:22:57 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 09:22:57 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>

On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae at richarde.dev> 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-ghc-extensions.rst#criteria
> .
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/d1a76c99/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 08:31:24 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 09:31:24 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
Message-ID: <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>

>
>    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 <arnaud.spiwack at tweag.io>
wrote:

> On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae at richarde.dev> 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-ghc-extensions.rst#criteria
>> .
>>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/bc37e165/attachment.html>

From marlowsd at gmail.com  Fri Dec  4 08:46:48 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 4 Dec 2020 08:46:48 +0000
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>

That is an infelicity, I agree. However, ScopedTypeVariables fills a
massive hole in Haskell, namely the inability to give a type signature to a
local function when the type involves type variables bound by an outer
scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I
understand the concerns.

Cheers
Simon

On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> I'd like to make a small plea against ScopedTypeVariables.
>
> * First off, I love (most of) ScopedTypeVariables, and enable it
> liberally. It is a safe extension.
>
> * But I very much dislike the way it brings variables into scope from
> `forall`s. When I write
>
> > f :: forall a. a -> a
> > f x = (x :: a)
>
> I find it very odd that `a` is brought into scope in the body of f.
> Compare to
>
> > f :: (forall a. a -> a)
> > f x = (x :: a)
>
> where I have added parentheses to the type of f. Now `a` is not in scope
> in the body of f. That's bizarre.
>
> * Note that type signatures and function definitions can be arbitrarily
> separated in a file. Some programmers indeed prefer to do this, so that
> type signatures can all be in one place, forming an interface to the file.
> (I've even seen header files, included via CPP!) I'm not necessarily
> advocating for that style, but I can't quite say it's absurd. Our ML
> friends do this reflexively.
>
> * I'm hoping ScopedTypeVariables will lose this feature in the future.
> I've been meaning to propose such for some time. See
> https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523,
> which re-slices this cake.
>
> Thus, given the potential for change in the future, and some drawbacks of
> the extension as it currently stands, I think we should not enable it by
> default, making change harder in the future.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/fa70e7bb/attachment.html>

From mail at joachim-breitner.de  Fri Dec  4 09:35:43 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 10:35:43 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <cd5c5bee-56a6-4d5c-a474-7f8e4610eb82@www.fastmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com>
 <CAHnFXOtpEqG2f-ArX2+LgybU0wbydg8h_mmZXvfRaVKyrHEA1Q@mail.gmail.com>
 <ff27f870f1c77ef736e10834b4a58eceaab5ad28.camel@joachim-breitner.de>
 <CANsrgP+dCt7urzPyNv9RuYqubAhpH3PWQXJ5fR=coyxHEqcQ2w@mail.gmail.com>
 <CAH6fHQmKkt+RUioAkZgSu=oUzbbF+S2bswVYhSQ5kxWWhyFEwA@mail.gmail.com>
 <DAAA735E-0378-4D60-A999-C03714470020@live.co.uk>
 <028eca5fc6830194ff1940d38715e9a9c5da1b28.camel@joachim-breitner.de>
 <CANsrgPLTaN2+eLgj+DXz4mxFt1T6kzWhHHCmq7fPoSxXMM2Vuw@mail.gmail.com>
 <CAH6fHQnnFcCHZWtv3MtsW8aXb=FSBhph-C0bM6Lq+_yukeyNyQ@mail.gmail.com>
 <CAHnFXOv5pf4P8iP71zeenprdgq20PPk6MODAge4dGiM_bewO_g@mail.gmail.com>
 <cd5c5bee-56a6-4d5c-a474-7f8e4610eb82@www.fastmail.com>
Message-ID: <f3b258fbd4929e78ec993305539fd192572d0296.camel@joachim-breitner.de>

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.html#extension-EmptyDataDeriving
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From marlowsd at gmail.com  Fri Dec  4 09:57:07 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 4 Dec 2020 09:57:07 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
Message-ID: <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>

On Fri, 4 Dec 2020 at 08:32, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

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

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?

Cheers
Simon

<https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/76231df3/attachment.html>

From mail at joachim-breitner.de  Fri Dec  4 10:57:05 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 11:57:05 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
Message-ID: <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>

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#context-free-syntax
       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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From tomjharding at live.co.uk  Fri Dec  4 11:07:33 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Fri, 4 Dec 2020 11:07:33 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
Message-ID: <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>

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 <mail at joachim-breitner.de> 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#context-free-syntax
>       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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From trupill at gmail.com  Fri Dec  4 11:14:47 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Dec 2020 03:14:47 -0800
Subject: [ghc-steering-committee]  #380 GHC2021: StarIsType
In-Reply-To: <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
Message-ID: <CAHnFXOsZiK0aSworxn5ZmW_F54zKfKE_rkvJHsP9gR5PhXLAxw@mail.gmail.com>

 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 <tomjharding at live.co.uk> 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 <mail at joachim-breitner.de>
> 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#context-free-syntax
>
>       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 at joachim-breitner.de
>
>  http://www.joachim-breitner.de/
>
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at haskell.org
>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/f6e80977/attachment-0001.html>

From mail at joachim-breitner.de  Fri Dec  4 11:24:01 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 12:24:01 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
Message-ID: <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>

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



From tomjharding at live.co.uk  Fri Dec  4 11:23:55 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Fri, 4 Dec 2020 11:23:55 +0000
Subject: [ghc-steering-committee] #380 GHC2021: StarIsType
In-Reply-To: <CAHnFXOsZiK0aSworxn5ZmW_F54zKfKE_rkvJHsP9gR5PhXLAxw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <CAHnFXOsZiK0aSworxn5ZmW_F54zKfKE_rkvJHsP9gR5PhXLAxw@mail.gmail.com>
Message-ID: <0C3ADB59-D5BE-4D3B-961C-47B0181A389C@live.co.uk>

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 <trupill at gmail.com<mailto:trupill at gmail.com>> 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 <tomjharding at live.co.uk<mailto:tomjharding at live.co.uk>> 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 <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> 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#context-free-syntax
      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 at joachim-breitner.de<mailto:mail at joachim-breitner.de>
 http://www.joachim-breitner.de/


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/445b26ef/attachment-0001.html>

From tomjharding at live.co.uk  Fri Dec  4 11:30:38 2020
From: tomjharding at live.co.uk (Tom Harding)
Date: Fri, 4 Dec 2020 11:30:38 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>
Message-ID: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>

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 <mail at joachim-breitner.de> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simonpj at microsoft.com  Fri Dec  4 12:04:39 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Dec 2020 12:04:39 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02224D180273B72572BD288AADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 04 December 2020 10:57
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf874fa603
|  d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267634
|  53649777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
|  CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TyAnHPLdYOjeChFOF%2FMUa
|  zyP1%2BHhV2xjoPtxmSWS1CU%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1f
|  caf874fa603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7
|  C637426763453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
|  oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BPYOFqz9V658
|  8IlquzjzcwAd8Oq9NbiOt86S2EG2Iq4%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf
|  874fa603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63
|  7426763453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BKmPtIIneF9ke
|  9RBN5VKFJ8a2pk16UOWA%2BOGOZ3zB7o%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87f3f1fcaf874fa
|  603d908d898435d86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267
|  63453659765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=X44d0g%2Bd4rYDI86U1p
|  3OQQC4E0b%2BzU2cpWfKj3h02VM%3D&amp;reserved=0

From simonpj at microsoft.com  Fri Dec  4 12:09:20 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Dec 2020 12:09:20 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0222A4BF61E5EB0D9782C701ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 04 December 2020 11:24
|  To: ghc-steering-committee at 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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da218
|  274565766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63
|  7426779203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=al%2FPwBdOBMsmI
|  v%2F7hH3ce%2BdPCKa9K6e%2BMtfRs2vteaY%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da21827456
|  5766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267
|  79203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DvDb4rRCvnRN%2BcqM4E
|  QSIf8kSXNypMnD6PZANjCENQI%3D&amp;reserved=0

From eric at seidel.io  Fri Dec  4 12:16:48 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 4 Dec 2020 07:16:48 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <f3b258fbd4929e78ec993305539fd192572d0296.camel@joachim-breitner.de>
References: <f3b258fbd4929e78ec993305539fd192572d0296.camel@joachim-breitner.de>
Message-ID: <8D9C68DD-0F3C-45AB-96A5-03C2251BE12C@seidel.io>

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 <mail at joachim-breitner.de> 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.html#extension-EmptyDataDeriving
> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Fri Dec  4 12:33:12 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 4 Dec 2020 07:33:12 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
Message-ID: <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>

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 <tomjharding at live.co.uk> 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 <mail at joachim-breitner.de> 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 at joachim-breitner.de
>> http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From arnaud.spiwack at tweag.io  Fri Dec  4 12:35:25 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:35:25 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <VI1PR83MB0222A4BF61E5EB0D9782C701ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <6ab75623436187f60c172c966a879465170583fc.camel@joachim-breitner.de>
 <VI1PR83MB0222A4BF61E5EB0D9782C701ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQkAx_SwmGRJ=JCWESsH4qU_G6wgBfoUnaqFzUBJVsUimQ@mail.gmail.com>

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 1:09 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> |  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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 04 December 2020 11:24
> |  To: ghc-steering-committee at 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 at joachim-breitner.de
> |
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  oachim-
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da218
> |  274565766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63
> |  7426779203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=al%2FPwBdOBMsmI
> |  v%2F7hH3ce%2BdPCKa9K6e%2BMtfRs2vteaY%3D&amp;reserved=0
> |
> |
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C71fd2da21827456
> |  5766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267
> |  79203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DvDb4rRCvnRN%2BcqM4E
> |  QSIf8kSXNypMnD6PZANjCENQI%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/d8738c74/attachment-0001.html>

From mail at joachim-breitner.de  Fri Dec  4 12:41:14 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 13:41:14 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
Message-ID: <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>

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



From arnaud.spiwack at tweag.io  Fri Dec  4 12:43:36 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:43:36 +0100
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with Functional
	dependencies
Message-ID: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>

Dear all,

It seems that a number of us have voted against including
FunctionalDependencies and  TypeFamilyDependencies.

I don't understand why. They are properly guarded by syntax. I don't know
any complaint against them FunctionalDependencies, at least, is as standard
as it gets (there are functional dependencies all over the mtl).

Is it an oversight? Or do some of us really believe that we ought to keep
these out, and why?

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/f078d08d/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 12:47:58 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:47:58 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
Message-ID: <CAH6fHQ=sSj6cXhZgKXFN2hJUKzCa5a5Lfu7Lx8zMGJcehRfiyg@mail.gmail.com>

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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/2e16ea59/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 12:49:06 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:49:06 +0100
Subject: [ghc-steering-committee] #380 GHC2021: StarIsType
In-Reply-To: <0C3ADB59-D5BE-4D3B-961C-47B0181A389C@live.co.uk>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <CAHnFXOsZiK0aSworxn5ZmW_F54zKfKE_rkvJHsP9gR5PhXLAxw@mail.gmail.com>
 <0C3ADB59-D5BE-4D3B-961C-47B0181A389C@live.co.uk>
Message-ID: <CAH6fHQk+c2cfxzOqFYQiv3i58kaJQrsH+40qAM0hPKqNFec31w@mail.gmail.com>

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 <tomjharding at live.co.uk> 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 <trupill at gmail.com> 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 <tomjharding at live.co.uk> 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 <mail at joachim-breitner.de>
>> 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#context-free-syntax
>>
>>       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 at joachim-breitner.de
>>
>>  http://www.joachim-breitner.de/
>>
>>
>>
>> _______________________________________________
>>
>> ghc-steering-committee mailing list
>>
>> ghc-steering-committee at haskell.org
>>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/ba271014/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 12:52:03 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:52:03 +0100
Subject: [ghc-steering-committee] #380 GHC2021: StarIsType
In-Reply-To: <0C3ADB59-D5BE-4D3B-961C-47B0181A389C@live.co.uk>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <512df3be963c3a1c3de34733c5a58e11cf3234c9.camel@joachim-breitner.de>
 <CAHnFXOvqmYi6mSNzXVxDAJ=Wgjkeb_iZ82Um7vBZNOj408M5aw@mail.gmail.com>
 <010f0176297279d0-86b5041f-4128-4ef4-9339-81815a425dab-000000@us-east-2.amazonses.com>
 <VI1PR83MB0222D86CAA474CC3A9044D0DADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <010f017629a81e4c-43aa6066-b743-4c70-80b1-128d2318a299-000000@us-east-2.amazonses.com>
 <CAH6fHQ=U1zpJwS0bqE_GsxiRHR4a+cqQGDgsCyCp+qb0nx6sQg@mail.gmail.com>
 <CAH6fHQ=stnXpOwyXXS+7BQAhfG0Z0mzuWjxn+sBV7_AUntKVzw@mail.gmail.com>
 <CANsrgP+6EW3W-shSGnn3DkH6L9hLDX9Nx1N3Te11zXsDH=DK1Q@mail.gmail.com>
 <21a68b06deb32e8326cb604ab1375b595cbd94a3.camel@joachim-breitner.de>
 <01FF0BA3-E1DC-4B11-8189-24670F973D63@live.co.uk>
 <CAHnFXOsZiK0aSworxn5ZmW_F54zKfKE_rkvJHsP9gR5PhXLAxw@mail.gmail.com>
 <0C3ADB59-D5BE-4D3B-961C-47B0181A389C@live.co.uk>
Message-ID: <CAH6fHQmqfVEMUmnViATKkzcXbuFvhimH7Sx8LUCyKZX_bb0Luw@mail.gmail.com>

On Fri, Dec 4, 2020 at 12:24 PM Tom Harding <tomjharding at live.co.uk> 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?
>

I believe that the agreement, based on the proposal that's been accepted
and the discussions around it, is that this is very much not a
`-XKitchenSink`-type extension. This is a set of reasonable defaults.
GHC2021 is the way GHC advertises it should be used (in 2021). Something
anybody can turn on without a second thought. I don't know if it ought to
appear in default cabal files, though it would definitely be reasonable
according the the extension's goal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/b63a782c/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 12:59:43 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 13:59:43 +0100
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
 <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>
Message-ID: <CAH6fHQm_pGo=ARuLnuBKRN6T90G80+XGcewsRJK3Z86aSs1vKw@mail.gmail.com>

I'm still undecided about ScopedTypeVariables (my vote says: maybe),
because there are a number of discussions about changing this or that part
of the semantics.

That being said: I always turn ScopedTypeVariables on. I'd _love_ for it to
be the default. The syntax is quirky, but I don't mind adding explicit
`forall`-s. Type signatures on patterns, I don't care much about: I use
them rarely. But the ability to bind a variable from the type signature
inside the term, this is a very essential feature. I'd be just as happy
with `\@a`, though.

I'm very much on the fence here. Though, this is just the first time around
for GHCXXXX, we can afford to be more conservative than on the next rounds.
So given that there are doubts around this extension, maybe it's best to
leave it out. And have a more ernest discussion for the second round.

On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow <marlowsd at gmail.com> wrote:

> That is an infelicity, I agree. However, ScopedTypeVariables fills a
> massive hole in Haskell, namely the inability to give a type signature to a
> local function when the type involves type variables bound by an outer
> scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I
> understand the concerns.
>
> Cheers
> Simon
>
> On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Hi all,
>>
>> I'd like to make a small plea against ScopedTypeVariables.
>>
>> * First off, I love (most of) ScopedTypeVariables, and enable it
>> liberally. It is a safe extension.
>>
>> * But I very much dislike the way it brings variables into scope from
>> `forall`s. When I write
>>
>> > f :: forall a. a -> a
>> > f x = (x :: a)
>>
>> I find it very odd that `a` is brought into scope in the body of f.
>> Compare to
>>
>> > f :: (forall a. a -> a)
>> > f x = (x :: a)
>>
>> where I have added parentheses to the type of f. Now `a` is not in scope
>> in the body of f. That's bizarre.
>>
>> * Note that type signatures and function definitions can be arbitrarily
>> separated in a file. Some programmers indeed prefer to do this, so that
>> type signatures can all be in one place, forming an interface to the file.
>> (I've even seen header files, included via CPP!) I'm not necessarily
>> advocating for that style, but I can't quite say it's absurd. Our ML
>> friends do this reflexively.
>>
>> * I'm hoping ScopedTypeVariables will lose this feature in the future.
>> I've been meaning to propose such for some time. See
>> https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523,
>> which re-slices this cake.
>>
>> Thus, given the potential for change in the future, and some drawbacks of
>> the extension as it currently stands, I think we should not enable it by
>> default, making change harder in the future.
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/696c490f/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 13:12:51 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 14:12:51 +0100
Subject: [ghc-steering-committee] #380 GHC2021: A plea for GADTs
Message-ID: <CAH6fHQm5E=Y1ka-7-igb0F0k1eZt3E+EvbwoTodUDAZ-Q1DYng@mail.gmail.com>

It seems that GADTs are on the fence. There has been a discussion in the
main thread.

I, personally, see no reason not to include them: GADTs have their own
syntax, and therefore don't interfere with programmers who want to remain
oblivious of them.

So I think they deserve their own thread.


Below the conversation so far

Here is what Alejandro had to say about GADTs

> - 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.)
>

Here is Simon PJ

> 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 😊.
>

 Here is Tom

> 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 :)
>

Here is Simon M

> I agree with Simon that we must have GADTs!
>

Here is Richard

>
> On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at 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!
>

Simon PJ again

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

 Richard agin

> On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones <simonpj at microsoft.com>
> 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-ghc-extensions.rst#criteria
> .
>

Arnaud

> On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae at richarde.dev> 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-ghc-extensions.rst#criteria
>> .
>>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/dfedb29e/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 13:22:48 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 14:22:48 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
	ExistentialQuantification
Message-ID: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>

Dear all,

ExistentialQuantification is one of the extensions that we are considering
adding to GHC2021.

ExistentialQuantificaton enables the following syntax:

data Dyn = forall a. Typeable a => MkDyn a

Has any of us actually used this syntax in recent years? I, personally,
only use the equivalent GADT syntax

data Dyn where
  MkDyn :: forall a. Typeable a => a -> Dyn a

It’s barely more verbose, and it’s less quirky.

Besides, the GADT syntax is there to stay (and GADTSyntax at the very
least, is one of these extensions where there seems to be no doubt will be
in GHC2021).

I’d say there is such a thing as too much syntax. And, in my view, the GADT
syntax makes the ExistentialQuantification syntax redundant. I’d much
rather we didn’t add it in the defaults so that it can be on its slow path
to deprecation.

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/beaa753b/attachment.html>

From eric at seidel.io  Fri Dec  4 13:25:19 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 08:25:19 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
Message-ID: <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>

On Fri, Dec 4, 2020, at 07:41, Joachim Breitner wrote:
> 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.

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.

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

Agreed that having a complete set of extensions in GHCi by default would be very nice, and the potential for breakage is not so concerning there. I'm less sure about the potential for breakage in standalone scripts using runghc or the stack/cabal script feature. I don't think I use that mode anywhere, so I don't have a good intuition for how people use it. If these scripts are deployed to "production" I'd be pretty concerned about the potential for breakage, but if they're just used for ad-hoc tasks I'd be less concerned. (One thing to note is that stack scripts at least will specify a particular ghc version via the resolver, so we don't have to worry there.)

All that said, if the argument is that we expect all "serious" uses to specify a default-language via Cabal, and thus have to explicitly opt into GHC2021, then why shouldn't we make some bold choices?

From trupill at gmail.com  Fri Dec  4 13:26:48 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Dec 2020 14:26:48 +0100
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <CAH6fHQm_pGo=ARuLnuBKRN6T90G80+XGcewsRJK3Z86aSs1vKw@mail.gmail.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
 <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>
 <CAH6fHQm_pGo=ARuLnuBKRN6T90G80+XGcewsRJK3Z86aSs1vKw@mail.gmail.com>
Message-ID: <CAHnFXOsSoO1fzwVd6GOMGjDXWsOWs3C70hx3EhX-BfVsBv8bxg@mail.gmail.com>

I'll reiterate my main point: ScopedTypeVariables is a very useful
extension, and one which a lot of people would like to see in the default
set. I would be happy to see it removed in a next iteration of the GHC20XX
if a better story comes along, but even if we nail the design now, we would
need to wait a few years for it to stabilize before inclusion. In the
meanwhile, everybody would be wondering why ScopedTypeVariable is not the
default.

El vie, 4 dic 2020 a las 14:00, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
escribió:

> I'm still undecided about ScopedTypeVariables (my vote says: maybe),
> because there are a number of discussions about changing this or that part
> of the semantics.
>
> That being said: I always turn ScopedTypeVariables on. I'd _love_ for it
> to be the default. The syntax is quirky, but I don't mind adding explicit
> `forall`-s. Type signatures on patterns, I don't care much about: I use
> them rarely. But the ability to bind a variable from the type signature
> inside the term, this is a very essential feature. I'd be just as happy
> with `\@a`, though.
>
> I'm very much on the fence here. Though, this is just the first time
> around for GHCXXXX, we can afford to be more conservative than on the next
> rounds. So given that there are doubts around this extension, maybe it's
> best to leave it out. And have a more ernest discussion for the second
> round.
>
> On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> That is an infelicity, I agree. However, ScopedTypeVariables fills a
>> massive hole in Haskell, namely the inability to give a type signature to a
>> local function when the type involves type variables bound by an outer
>> scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I
>> understand the concerns.
>>
>> Cheers
>> Simon
>>
>> On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to make a small plea against ScopedTypeVariables.
>>>
>>> * First off, I love (most of) ScopedTypeVariables, and enable it
>>> liberally. It is a safe extension.
>>>
>>> * But I very much dislike the way it brings variables into scope from
>>> `forall`s. When I write
>>>
>>> > f :: forall a. a -> a
>>> > f x = (x :: a)
>>>
>>> I find it very odd that `a` is brought into scope in the body of f.
>>> Compare to
>>>
>>> > f :: (forall a. a -> a)
>>> > f x = (x :: a)
>>>
>>> where I have added parentheses to the type of f. Now `a` is not in scope
>>> in the body of f. That's bizarre.
>>>
>>> * Note that type signatures and function definitions can be arbitrarily
>>> separated in a file. Some programmers indeed prefer to do this, so that
>>> type signatures can all be in one place, forming an interface to the file.
>>> (I've even seen header files, included via CPP!) I'm not necessarily
>>> advocating for that style, but I can't quite say it's absurd. Our ML
>>> friends do this reflexively.
>>>
>>> * I'm hoping ScopedTypeVariables will lose this feature in the future.
>>> I've been meaning to propose such for some time. See
>>> https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523,
>>> which re-slices this cake.
>>>
>>> Thus, given the potential for change in the future, and some drawbacks
>>> of the extension as it currently stands, I think we should not enable it by
>>> default, making change harder in the future.
>>>
>>> Thanks,
>>> Richard
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/7a56c5bf/attachment-0001.html>

From eric at seidel.io  Fri Dec  4 13:31:43 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 08:31:43 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23380_GHC2021=3A_Let=27s_depr?=
 =?utf-8?q?ecate=09ExistentialQuantification?=
In-Reply-To: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
Message-ID: <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>

I do use ExistentialQuantification on occasion, but mainly because I'm used to it and don't often use GADT syntax. I'm not strongly attached to it, in fact now that you spelled out the GADT version

> data Dyn where
>   MkDyn :: forall a. Typeable a => a -> Dyn

I think that makes the existential quite a bit clearer, so I might start using it :)

On Fri, Dec 4, 2020, at 08:22, Spiwack, Arnaud wrote:
> Dear all,
> 
> ExistentialQuantification is one of the extensions that we are 
> considering adding to GHC2021.
> 
> ExistentialQuantificaton enables the following syntax:
> 
> `data Dyn = forall a. Typeable a => MkDyn a
> ` 
> Has any of us actually used this syntax in recent years? I, personally, 
> only use the equivalent GADT syntax
> 
> `data Dyn where
>   MkDyn :: forall a. Typeable a => a -> Dyn a
> ` 
> It’s barely more verbose, and it’s less quirky.
> 
> Besides, the GADT syntax is there to stay (and GADTSyntax at the very 
> least, is one of these extensions where there seems to be no doubt will 
> be in GHC2021).
> 
> I’d say there is such a thing as too much syntax. And, in my view, the 
> GADT syntax makes the ExistentialQuantification syntax redundant. I’d 
> much rather we didn’t add it in the defaults so that it can be on its 
> slow path to deprecation.
> 
> /Arnaud
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From arnaud.spiwack at tweag.io  Fri Dec  4 13:39:44 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 14:39:44 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
Message-ID: <CAH6fHQ=94WTfhcqhTRM9n5T82p_jbieme-vsbOLFS1ndsWSVwA@mail.gmail.com>

On Fri, Dec 4, 2020 at 2:25 PM Eric Seidel <eric at seidel.io> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/06abc197/attachment.html>

From trupill at gmail.com  Fri Dec  4 13:40:22 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Dec 2020 14:40:22 +0100
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with
 Functional dependencies
In-Reply-To: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
References: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
Message-ID: <CAHnFXOtEUBDC+NifNv+h2DhT0FLtzZp_0wOvEwqaaT+tYe_rKA@mail.gmail.com>

I voted "maybe", since I wasn't unsure about FunctionalDependencies. My
line of thought was "since only the creator of the class has to enable it,
it's not so terrible". On the other hand, I agree with your comment about
being properly guarded by syntax, which is sort of my golden rule.

About TypeFamilyDependencies, I think it's too early for inclusion. I don't
think the design has settled yet, in particular because you cannot write
very complex dependencies right now.

El vie, 4 dic 2020 a las 13:44, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
escribió:

> Dear all,
>
> It seems that a number of us have voted against including
> FunctionalDependencies and  TypeFamilyDependencies.
>
> I don't understand why. They are properly guarded by syntax. I don't know
> any complaint against them FunctionalDependencies, at least, is as standard
> as it gets (there are functional dependencies all over the mtl).
>
> Is it an oversight? Or do some of us really believe that we ought to keep
> these out, and why?
>
> /Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/3c7c25e7/attachment.html>

From trupill at gmail.com  Fri Dec  4 13:41:11 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Dec 2020 14:41:11 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
	ExistentialQuantification
In-Reply-To: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
Message-ID: <CAHnFXOtq8FDhJOr5caWsYwGOM7h2hHCYn808kvdhjUJ+ffhyrQ@mail.gmail.com>

Agree! Try to steering people to either use the "simple ADT" or go to "full
GADT" syntax seems a good plan to me.

El vie, 4 dic 2020 a las 14:23, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
escribió:

> Dear all,
>
> ExistentialQuantification is one of the extensions that we are considering
> adding to GHC2021.
>
> ExistentialQuantificaton enables the following syntax:
>
> data Dyn = forall a. Typeable a => MkDyn a
>
> Has any of us actually used this syntax in recent years? I, personally,
> only use the equivalent GADT syntax
>
> data Dyn where
>   MkDyn :: forall a. Typeable a => a -> Dyn a
>
> It’s barely more verbose, and it’s less quirky.
>
> Besides, the GADT syntax is there to stay (and GADTSyntax at the very
> least, is one of these extensions where there seems to be no doubt will be
> in GHC2021).
>
> I’d say there is such a thing as too much syntax. And, in my view, the
> GADT syntax makes the ExistentialQuantification syntax redundant. I’d much
> rather we didn’t add it in the defaults so that it can be on its slow path
> to deprecation.
>
> /Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/a541c74e/attachment-0001.html>

From trupill at gmail.com  Fri Dec  4 13:45:04 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Dec 2020 05:45:04 -0800
Subject: [ghc-steering-committee] CUSKs and StandaloneTypeSignatures
Message-ID: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>

Maybe some part of this discussion got lost.

Simon PJ writes:

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


I would really like StandaloneTypeSignatures to be part of the default, and
remove CUSKs. Thoughts on this? Is it too early?

Regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/4ca40aee/attachment.html>

From simonpj at microsoft.com  Fri Dec  4 14:07:38 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Dec 2020 14:07:38 +0000
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with
 Functional	dependencies
In-Reply-To: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
References: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
Message-ID: <VI1PR83MB02223B27858807DA52D3D949ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>

We’re back to “what is GHC2021 for?”   Maybe we need to refine the criteria.

Arnaud seems to be saying “anything that is guarded by its own syntax, and is widely used, should go in”.   But GHC2020 is also saying “these are blessed extensions that are well understood and we expect to be part of the language forever”.

You could argue that fundeps are in that class.   But let’s not forget the “expect to be part of the language forever”.   For me, standalone kind signatures are definitely “forever”.  But fundeps – because they don’t carry evidence, as they stand – feel less solidly rooted.

Simon


From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Spiwack, Arnaud
Sent: 04 December 2020 12:44
To: GHC Steering Committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with Functional dependencies

Dear all,

It seems that a number of us have voted against including FunctionalDependencies and  TypeFamilyDependencies.

I don't understand why. They are properly guarded by syntax. I don't know any complaint against them FunctionalDependencies, at least, is as standard as it gets (there are functional dependencies all over the mtl).

Is it an oversight? Or do some of us really believe that we ought to keep these out, and why?

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/99edcca1/attachment.html>

From eric at seidel.io  Fri Dec  4 14:09:17 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 09:09:17 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23380_GHC2021=3A_Let=27s_depr?=
 =?utf-8?q?ecate=09ExistentialQuantification?=
In-Reply-To: <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
Message-ID: <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>

Ah one clarification, GADTSyntax alone does not enable existential types. You need to enable either ExistentialQuantification or full GADTs.

ghc2020.hs:8:3: error:
    • Data constructor ‘MkDyn’ has existential type variables, a context, or a specialised result type
        MkDyn :: forall a. Typeable a => a -> Dyn
        (Enable ExistentialQuantification or GADTs to allow this)
    • In the definition of data constructor ‘MkDyn’
      In the data type declaration for ‘Dyn’

But if we are going to enable GADTs by default, then there's still not much need for the old syntax.

On Fri, Dec 4, 2020, at 08:31, Eric Seidel wrote:
> I do use ExistentialQuantification on occasion, but mainly because I'm 
> used to it and don't often use GADT syntax. I'm not strongly attached 
> to it, in fact now that you spelled out the GADT version
> 
> > data Dyn where
> >   MkDyn :: forall a. Typeable a => a -> Dyn
> 
> I think that makes the existential quite a bit clearer, so I might 
> start using it :)
> 
> On Fri, Dec 4, 2020, at 08:22, Spiwack, Arnaud wrote:
> > Dear all,
> > 
> > ExistentialQuantification is one of the extensions that we are 
> > considering adding to GHC2021.
> > 
> > ExistentialQuantificaton enables the following syntax:
> > 
> > `data Dyn = forall a. Typeable a => MkDyn a
> > ` 
> > Has any of us actually used this syntax in recent years? I, personally, 
> > only use the equivalent GADT syntax
> > 
> > `data Dyn where
> >   MkDyn :: forall a. Typeable a => a -> Dyn a
> > ` 
> > It’s barely more verbose, and it’s less quirky.
> > 
> > Besides, the GADT syntax is there to stay (and GADTSyntax at the very 
> > least, is one of these extensions where there seems to be no doubt will 
> > be in GHC2021).
> > 
> > I’d say there is such a thing as too much syntax. And, in my view, the 
> > GADT syntax makes the ExistentialQuantification syntax redundant. I’d 
> > much rather we didn’t add it in the defaults so that it can be on its 
> > slow path to deprecation.
> > 
> > /Arnaud
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >

From arnaud.spiwack at tweag.io  Fri Dec  4 14:12:42 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 15:12:42 +0100
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with
 Functional dependencies
In-Reply-To: <VI1PR83MB02223B27858807DA52D3D949ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
 <VI1PR83MB02223B27858807DA52D3D949ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQm5gQYoVxLANobGtV4GatCz8iWc4BKQdcrVCrx3he+4AA@mail.gmail.com>

On Fri, Dec 4, 2020 at 3:07 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> But fundeps – because they don’t carry evidence, as they stand – feel less
> solidly rooted.
>

Can you elaborate? I don't understand where you are coming from yet.

(for the record: I'm not applying just “guarded by their own syntax” as a
criterion, for me, this criterion is a sufficient condition for “no
surprising new errors”. I also believe (believed?) that functional
dependencies were quite standard and expected them to be here forever. I
took TypeFamilyDependency to be a mild extension. I'm perfectly willing to
be convinced otherwise.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/ec3a4cc2/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 14:14:08 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 15:14:08 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
	ExistentialQuantification
In-Reply-To: <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
 <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
Message-ID: <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>

> Ah one clarification, GADTSyntax alone does not enable existential types.
> You need to enable either ExistentialQuantification or full GADTs.
>

It makes more than perfect sense, but I wasn't aware of this. A consequence
of always enabling -XGADTs, I suppose :-) .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/fd10588e/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 14:15:35 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 15:15:35 +0100
Subject: [ghc-steering-committee] CUSKs and StandaloneTypeSignatures
In-Reply-To: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>
References: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>
Message-ID: <CAH6fHQnUsPxWgB=vnd4nM-ianoyyONCZ5-3LQuGA8WzHLupUTw@mail.gmail.com>

CUSKs need to go. I see no place for them in the defaults.

I want StandaloneKindSignature in the default too, but I think that they
are not battle-tested enough to be included this time around.

On Fri, Dec 4, 2020 at 2:45 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Maybe some part of this discussion got lost.
>
> Simon PJ writes:
>
> 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.
>>
>
>
> I would really like StandaloneTypeSignatures to be part of the default,
> and remove CUSKs. Thoughts on this? Is it too early?
>
> Regards,
> Alejandro
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/fbcca34e/attachment.html>

From simonpj at microsoft.com  Fri Dec  4 14:28:53 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Dec 2020 14:28:53 +0000
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with
 Functional dependencies
In-Reply-To: <CAH6fHQm5gQYoVxLANobGtV4GatCz8iWc4BKQdcrVCrx3he+4AA@mail.gmail.com>
References: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
 <VI1PR83MB02223B27858807DA52D3D949ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQm5gQYoVxLANobGtV4GatCz8iWc4BKQdcrVCrx3he+4AA@mail.gmail.com>
Message-ID: <VI1PR83MB0222D8394F00F75499E6A734ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Can you elaborate? I don't understand where you are coming from yet.

In haste,

  *   Many open tickets about fundeps<https://gitlab.haskell.org/ghc/ghc/-/issues?label_name=FunctionalDependencies>… still open because of lack of agreement about what the Right Thing is, not because the implementation is difficult
  *   As originally proposed they are quite restrictive (the Coverage Condition).  Many uses of fundeps use a more liberal coverage condition, currently enabled by UndecidableInstances.  I’m not sure if “Many” means “most” or just “a minority”; data needed.
  *   Fundeps affect unification in type inference, and have no effect in Givens, unlike type families. Nothing inherently wrong with that, but it feels unsatisfying that we can know that t1~t2 (from a fundep between two givens) but can’t exploit that fact.

They are undoubtedly useful. I’m not arguing for removal.  They have just never felt as solid to me as other parts of our type system.

Simon

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 04 December 2020 14:13
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: GHC Steering Committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #380 GHC2021: What's wrong with Functional dependencies

On Fri, Dec 4, 2020 at 3:07 PM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
But fundeps – because they don’t carry evidence, as they stand – feel less solidly rooted.

Can you elaborate? I don't understand where you are coming from yet.

(for the record: I'm not applying just “guarded by their own syntax” as a criterion, for me, this criterion is a sufficient condition for “no surprising new errors”. I also believe (believed?) that functional dependencies were quite standard and expected them to be here forever. I took TypeFamilyDependency to be a mild extension. I'm perfectly willing to be convinced otherwise.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/baaa3752/attachment-0001.html>

From rae at richarde.dev  Fri Dec  4 14:29:08 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 14:29:08 +0000
Subject: [ghc-steering-committee] CUSKs and StandaloneTypeSignatures
In-Reply-To: <CAH6fHQnUsPxWgB=vnd4nM-ianoyyONCZ5-3LQuGA8WzHLupUTw@mail.gmail.com>
References: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>
 <CAH6fHQnUsPxWgB=vnd4nM-ianoyyONCZ5-3LQuGA8WzHLupUTw@mail.gmail.com>
Message-ID: <010f01762e281a63-284bb851-6ffc-445e-a25d-bc42b4bfc9dd-000000@us-east-2.amazonses.com>

I think StandaloneKindSignatures should be included. It's true that there may be implementation bugs, but the design of them is really quite straightforward, so I don't expect design bugs. And I think it's design bugs that should hinder inclusion, much more than implementation bugs (of which I know none, at the moment).

Richard

> On Dec 4, 2020, at 9:15 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> CUSKs need to go. I see no place for them in the defaults.
> 
> I want StandaloneKindSignature in the default too, but I think that they are not battle-tested enough to be included this time around.
> 
> On Fri, Dec 4, 2020 at 2:45 PM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> Maybe some part of this discussion got lost.
> 
> Simon PJ writes:
> 
> 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.
> 
> 
> I would really like StandaloneTypeSignatures to be part of the default, and remove CUSKs. Thoughts on this? Is it too early?
> 
> Regards,
> Alejandro
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/45b747c9/attachment.html>

From rae at richarde.dev  Fri Dec  4 14:34:11 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 14:34:11 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
 ExistentialQuantification
In-Reply-To: <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
 <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
 <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>
Message-ID: <010f01762e2cb72a-86da0220-7ee4-4a09-b6f6-d4caafc31d75-000000@us-east-2.amazonses.com>

I do use the data Ex = forall a. ... syntax occasionally, but only when I'm emphasizing that I'm not building a GADT. I would entertain the thought of removing it. Yet, I don't think we can do so as part of this process, as we don't have a combination of extensions that allows GADT-syntax existentials but not this other syntax. (Even -XGADTs -XNoExistentialQuantification doesn't eliminate it.)

In any case, I've voted against GADTs, and so if you want to disentangle this one piece of syntax, that would also be a vote against GADTs, followed up with a proposal to spin out this syntax into its own extension.

Richard

> On Dec 4, 2020, at 9:14 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> 
> Ah one clarification, GADTSyntax alone does not enable existential types. You need to enable either ExistentialQuantification or full GADTs.
> 
> It makes more than perfect sense, but I wasn't aware of this. A consequence of always enabling -XGADTs, I suppose :-) .
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/bda083f0/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 14:40:33 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 15:40:33 +0100
Subject: [ghc-steering-committee] CUSKs and StandaloneTypeSignatures
In-Reply-To: <010f01762e281a63-284bb851-6ffc-445e-a25d-bc42b4bfc9dd-000000@us-east-2.amazonses.com>
References: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>
 <CAH6fHQnUsPxWgB=vnd4nM-ianoyyONCZ5-3LQuGA8WzHLupUTw@mail.gmail.com>
 <010f01762e281a63-284bb851-6ffc-445e-a25d-bc42b4bfc9dd-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=149jyvu2XLJMZ4vXyUVv9-2F--DvxkxoJ1KdGJqteXw@mail.gmail.com>

I agree that implementation bugs are not what we want to worry about. But
straightforward or not, StandaloneKindSignature's design has barely been
tested. It wouldn't be the first extension that we believed to be
unproblematic (I do believe it is!) and be surprised that there are some
dark corners. So I'd say let's give it a little time.

On Fri, Dec 4, 2020 at 3:29 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I think StandaloneKindSignatures should be included. It's true that there
> may be implementation bugs, but the design of them is really quite
> straightforward, so I don't expect design bugs. And I think it's design
> bugs that should hinder inclusion, much more than implementation bugs (of
> which I know none, at the moment).
>
> Richard
>
> On Dec 4, 2020, at 9:15 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> CUSKs need to go. I see no place for them in the defaults.
>
> I want StandaloneKindSignature in the default too, but I think that they
> are not battle-tested enough to be included this time around.
>
> On Fri, Dec 4, 2020 at 2:45 PM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> Maybe some part of this discussion got lost.
>>
>> Simon PJ writes:
>>
>> 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.
>>>
>>
>>
>> I would really like StandaloneTypeSignatures to be part of the default,
>> and remove CUSKs. Thoughts on this? Is it too early?
>>
>> Regards,
>> Alejandro
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/21f16574/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 14:47:28 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 15:47:28 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
	ExistentialQuantification
In-Reply-To: <010f01762e2cb72a-86da0220-7ee4-4a09-b6f6-d4caafc31d75-000000@us-east-2.amazonses.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
 <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
 <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>
 <010f01762e2cb72a-86da0220-7ee4-4a09-b6f6-d4caafc31d75-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQmGj=DbEsde2NH+ueADXqEM+oa0cc2zfZXX40Cc9bcFWA@mail.gmail.com>

I'm just saying: let's _not_ add ExistentialQuantification in GHC2021
(because it ought, in my opinion, to be considered deprecated). Let's not
go into talking about chopping the feature into smaller pieces. I do agree
that one of my arguments in the original email has been shown to be
incorrect, though. But I still think that my suggestion holds.

On Fri, Dec 4, 2020 at 3:34 PM Richard Eisenberg <rae at richarde.dev> wrote:

> I do use the data Ex = forall a. ... syntax occasionally, but only when
> I'm emphasizing that I'm not building a GADT. I would entertain the thought
> of removing it. Yet, I don't think we can do so as part of this process, as
> we don't have a combination of extensions that allows GADT-syntax
> existentials but not this other syntax. (Even -XGADTs
> -XNoExistentialQuantification doesn't eliminate it.)
>
> In any case, I've voted against GADTs, and so if you want to disentangle
> this one piece of syntax, that would also be a vote against GADTs, followed
> up with a proposal to spin out this syntax into its own extension.
>
> Richard
>
> On Dec 4, 2020, at 9:14 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>
> Ah one clarification, GADTSyntax alone does not enable existential types.
>> You need to enable either ExistentialQuantification or full GADTs.
>>
>
> It makes more than perfect sense, but I wasn't aware of this. A
> consequence of always enabling -XGADTs, I suppose :-) .
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/323277f4/attachment-0001.html>

From mail at joachim-breitner.de  Fri Dec  4 15:25:06 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 16:25:06 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
 ExistentialQuantification
In-Reply-To: <CAH6fHQmGj=DbEsde2NH+ueADXqEM+oa0cc2zfZXX40Cc9bcFWA@mail.gmail.com>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
 <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
 <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>
 <010f01762e2cb72a-86da0220-7ee4-4a09-b6f6-d4caafc31d75-000000@us-east-2.amazonses.com>
 <CAH6fHQmGj=DbEsde2NH+ueADXqEM+oa0cc2zfZXX40Cc9bcFWA@mail.gmail.com>
Message-ID: <6ee8a41d01fe0b9b277dc9ab8c10c3051f48283f.camel@joachim-breitner.de>

Hi,

Am Freitag, den 04.12.2020, 15:47 +0100 schrieb Spiwack, Arnaud:
> I'm just saying: let's _not_ add ExistentialQuantification in GHC2021
> (because it ought, in my opinion, to be considered deprecated).

I’m convinced!

>  Let's not go into talking about chopping the feature into smaller
> pieces. 

Not for GHC2021! But if GADTs don’t make it this round, we can ask the
question if ExistentialVariables is a feature worth having on its own,
of if anyone who wants to use that should just go for GADTs.


Cheers,
Joachim

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



From mail at joachim-breitner.de  Fri Dec  4 15:29:51 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 16:29:51 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
Message-ID: <872fec099df8002da39905ea176e9b0ff1a67a67.camel@joachim-breitner.de>

Hi,

Am Freitag, den 04.12.2020, 08:25 -0500 schrieb Eric Seidel:
> All that said, if the argument is that we expect all "serious" uses
> to specify a default-language via Cabal, and thus have to explicitly
> opt into GHC2021, then why shouldn't we make some bold choices?

It’s already bold enough what we are trying to do :-)

If bold means “opinionated, educating, risky of pissing people off”,
then I’d not want to go there. I hope we will _not_ get angry blog
posts about “This is killing Haskell, I will never ever use this” (or
at least not many of them). I hope this will not cause endless debates
and “wat”-like blog posts (like FTP maybe). 

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.

Cheers,
Joachim

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



From iavor.diatchki at gmail.com  Fri Dec  4 16:02:50 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:02:50 -0800
Subject: [ghc-steering-committee] #380 GHC2021: A plea for GADTs
In-Reply-To: <CAH6fHQm5E=Y1ka-7-igb0F0k1eZt3E+EvbwoTodUDAZ-Q1DYng@mail.gmail.com>
References: <CAH6fHQm5E=Y1ka-7-igb0F0k1eZt3E+EvbwoTodUDAZ-Q1DYng@mail.gmail.com>
Message-ID: <CAGK9nuopeKDnWoOPzJufTouQ+uf-ZM9poMs2Dmoua_pVP9vbcQ@mail.gmail.com>

I don't want GADTs to on by default, because pattern matching on them does
not work the same as with normal data types (i.e., you often need to have
an explicitly type signature, or be aware of GHC type checking algorithm to
know when a type signature is not needed).  So I'd like to be able to see
explicitly that GADTs might be in play.

On Fri, Dec 4, 2020 at 5:13 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> It seems that GADTs are on the fence. There has been a discussion in the
> main thread.
>
> I, personally, see no reason not to include them: GADTs have their own
> syntax, and therefore don't interfere with programmers who want to remain
> oblivious of them.
>
> So I think they deserve their own thread.
>
>
> Below the conversation so far
>
> Here is what Alejandro had to say about GADTs
>
>> - 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.)
>>
>
> Here is Simon PJ
>
>> 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 😊.
>>
>
>  Here is Tom
>
>> 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 :)
>>
>
> Here is Simon M
>
>> I agree with Simon that we must have GADTs!
>>
>
> Here is Richard
>
>>
>> On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at 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!
>>
>
> Simon PJ again
>
>> 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!
>>
>
>  Richard agin
>
>> On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones <simonpj at microsoft.com>
>> 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-ghc-extensions.rst#criteria
>> .
>>
>
> Arnaud
>
>> On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae at richarde.dev>
>> 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-ghc-extensions.rst#criteria
>>> .
>>>
>>
>> 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.
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/9e15b711/attachment.html>

From iavor.diatchki at gmail.com  Fri Dec  4 16:05:14 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:05:14 -0800
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <CAHnFXOsSoO1fzwVd6GOMGjDXWsOWs3C70hx3EhX-BfVsBv8bxg@mail.gmail.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
 <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>
 <CAH6fHQm_pGo=ARuLnuBKRN6T90G80+XGcewsRJK3Z86aSs1vKw@mail.gmail.com>
 <CAHnFXOsSoO1fzwVd6GOMGjDXWsOWs3C70hx3EhX-BfVsBv8bxg@mail.gmail.com>
Message-ID: <CAGK9nuoUUxwJ==u6RaPDQkCh=99A=_M3=zY=BcxkX3twSnUgzQ@mail.gmail.com>

I do think that ScopedTypeVariables are useful, but not so much unless you
are doing fancy type level programming (e.g., GADTs, type families, etc).
It is quite easy to do a lot of Haskell without them, so I'd be fine
without them in the standard.

On Fri, Dec 4, 2020 at 5:27 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I'll reiterate my main point: ScopedTypeVariables is a very useful
> extension, and one which a lot of people would like to see in the default
> set. I would be happy to see it removed in a next iteration of the GHC20XX
> if a better story comes along, but even if we nail the design now, we would
> need to wait a few years for it to stabilize before inclusion. In the
> meanwhile, everybody would be wondering why ScopedTypeVariable is not the
> default.
>
> El vie, 4 dic 2020 a las 14:00, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
> escribió:
>
>> I'm still undecided about ScopedTypeVariables (my vote says: maybe),
>> because there are a number of discussions about changing this or that part
>> of the semantics.
>>
>> That being said: I always turn ScopedTypeVariables on. I'd _love_ for it
>> to be the default. The syntax is quirky, but I don't mind adding explicit
>> `forall`-s. Type signatures on patterns, I don't care much about: I use
>> them rarely. But the ability to bind a variable from the type signature
>> inside the term, this is a very essential feature. I'd be just as happy
>> with `\@a`, though.
>>
>> I'm very much on the fence here. Though, this is just the first time
>> around for GHCXXXX, we can afford to be more conservative than on the next
>> rounds. So given that there are doubts around this extension, maybe it's
>> best to leave it out. And have a more ernest discussion for the second
>> round.
>>
>> On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> That is an infelicity, I agree. However, ScopedTypeVariables fills a
>>> massive hole in Haskell, namely the inability to give a type signature to a
>>> local function when the type involves type variables bound by an outer
>>> scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I
>>> understand the concerns.
>>>
>>> Cheers
>>> Simon
>>>
>>> On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'd like to make a small plea against ScopedTypeVariables.
>>>>
>>>> * First off, I love (most of) ScopedTypeVariables, and enable it
>>>> liberally. It is a safe extension.
>>>>
>>>> * But I very much dislike the way it brings variables into scope from
>>>> `forall`s. When I write
>>>>
>>>> > f :: forall a. a -> a
>>>> > f x = (x :: a)
>>>>
>>>> I find it very odd that `a` is brought into scope in the body of f.
>>>> Compare to
>>>>
>>>> > f :: (forall a. a -> a)
>>>> > f x = (x :: a)
>>>>
>>>> where I have added parentheses to the type of f. Now `a` is not in
>>>> scope in the body of f. That's bizarre.
>>>>
>>>> * Note that type signatures and function definitions can be arbitrarily
>>>> separated in a file. Some programmers indeed prefer to do this, so that
>>>> type signatures can all be in one place, forming an interface to the file.
>>>> (I've even seen header files, included via CPP!) I'm not necessarily
>>>> advocating for that style, but I can't quite say it's absurd. Our ML
>>>> friends do this reflexively.
>>>>
>>>> * I'm hoping ScopedTypeVariables will lose this feature in the future.
>>>> I've been meaning to propose such for some time. See
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523,
>>>> which re-slices this cake.
>>>>
>>>> Thus, given the potential for change in the future, and some drawbacks
>>>> of the extension as it currently stands, I think we should not enable it by
>>>> default, making change harder in the future.
>>>>
>>>> Thanks,
>>>> Richard
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/9a67702f/attachment-0001.html>

From iavor.diatchki at gmail.com  Fri Dec  4 16:11:19 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:11:19 -0800
Subject: [ghc-steering-committee] #380 GHC2021: What's wrong with
 Functional dependencies
In-Reply-To: <VI1PR83MB0222D8394F00F75499E6A734ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAH6fHQ=W81nb5dJiZ2Vz9-m4iTKWCCT8LjQpdFeFRERpucq0Dg@mail.gmail.com>
 <VI1PR83MB02223B27858807DA52D3D949ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQm5gQYoVxLANobGtV4GatCz8iWc4BKQdcrVCrx3he+4AA@mail.gmail.com>
 <VI1PR83MB0222D8394F00F75499E6A734ADF11@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupGTs=ro_cMeQj3-vk95r=6ffu7m_Asa2fsqyXyWFE8EQ@mail.gmail.com>

I like functional dependencies but I don't think they should be on by
default.  My main reason is that I don't know what's a good way to check FD
consistency:  I find the original FD consistency check to be a bit too
conservative, and the liberal coverage condition turned out to be unsound
(e.g. See Tom Schrijvers's paper about FDs).   I guess in part for such
reasons GHC has been very conservative about how it uses them (e.g., it
won't use them on given constraints).  This has led to a bunch of confusion
about what *is* a FD at all...  So I don't think their
design/implementation is in its final form, which is why I don't think the
extension should be on by default.

On Fri, Dec 4, 2020 at 6:29 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Can you elaborate? I don't understand where you are coming from yet.
>
>
>
> In haste,
>
>    - Many open tickets about fundeps
>    <https://gitlab.haskell.org/ghc/ghc/-/issues?label_name=FunctionalDependencies>…
>    still open because of lack of agreement about what the Right Thing is, not
>    because the implementation is difficult
>    - As originally proposed they are quite restrictive (the Coverage
>    Condition).  Many uses of fundeps use a more liberal coverage condition,
>    currently enabled by UndecidableInstances.  I’m not sure if “Many” means
>    “most” or just “a minority”; data needed.
>    - Fundeps affect unification in type inference, and have no effect in
>    Givens, unlike type families. Nothing inherently wrong with that, but it
>    feels unsatisfying that we can know that t1~t2 (from a fundep between two
>    givens) but can’t exploit that fact.
>
>
>
> They are undoubtedly useful. I’m not arguing for removal.  They have just
> never felt as solid to me as other parts of our type system.
>
>
>
> Simon
>
>
>
> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Sent:* 04 December 2020 14:13
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* GHC Steering Committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] #380 GHC2021: What's wrong with
> Functional dependencies
>
>
>
> On Fri, Dec 4, 2020 at 3:07 PM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> But fundeps – because they don’t carry evidence, as they stand – feel less
> solidly rooted.
>
>
>
> Can you elaborate? I don't understand where you are coming from yet.
>
>
>
> (for the record: I'm not applying just “guarded by their own syntax” as a
> criterion, for me, this criterion is a sufficient condition for “no
> surprising new errors”. I also believe (believed?) that functional
> dependencies were quite standard and expected them to be here forever. I
> took TypeFamilyDependency to be a mild extension. I'm perfectly willing to
> be convinced otherwise.)
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/b396adc4/attachment.html>

From iavor.diatchki at gmail.com  Fri Dec  4 16:12:00 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:12:00 -0800
Subject: [ghc-steering-committee] CUSKs and StandaloneTypeSignatures
In-Reply-To: <CAH6fHQ=149jyvu2XLJMZ4vXyUVv9-2F--DvxkxoJ1KdGJqteXw@mail.gmail.com>
References: <CAHnFXOuhM-USHaNxN9BUgg4M=zOd2cncv6AzyEvufainSmNg3g@mail.gmail.com>
 <CAH6fHQnUsPxWgB=vnd4nM-ianoyyONCZ5-3LQuGA8WzHLupUTw@mail.gmail.com>
 <010f01762e281a63-284bb851-6ffc-445e-a25d-bc42b4bfc9dd-000000@us-east-2.amazonses.com>
 <CAH6fHQ=149jyvu2XLJMZ4vXyUVv9-2F--DvxkxoJ1KdGJqteXw@mail.gmail.com>
Message-ID: <CAGK9nuokmmxCpHEdzy_v1CD1Ea4Sgx4hqss3-eos+j0Wo6a3Yw@mail.gmail.com>

I have never used one of these, so I have no strong opinion on what we do
here.

On Fri, Dec 4, 2020 at 6:41 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> I agree that implementation bugs are not what we want to worry about. But
> straightforward or not, StandaloneKindSignature's design has barely been
> tested. It wouldn't be the first extension that we believed to be
> unproblematic (I do believe it is!) and be surprised that there are some
> dark corners. So I'd say let's give it a little time.
>
> On Fri, Dec 4, 2020 at 3:29 PM Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I think StandaloneKindSignatures should be included. It's true that there
>> may be implementation bugs, but the design of them is really quite
>> straightforward, so I don't expect design bugs. And I think it's design
>> bugs that should hinder inclusion, much more than implementation bugs (of
>> which I know none, at the moment).
>>
>> Richard
>>
>> On Dec 4, 2020, at 9:15 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> CUSKs need to go. I see no place for them in the defaults.
>>
>> I want StandaloneKindSignature in the default too, but I think that they
>> are not battle-tested enough to be included this time around.
>>
>> On Fri, Dec 4, 2020 at 2:45 PM Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>>> Maybe some part of this discussion got lost.
>>>
>>> Simon PJ writes:
>>>
>>> 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.
>>>>
>>>
>>>
>>> I would really like StandaloneTypeSignatures to be part of the default,
>>> and remove CUSKs. Thoughts on this? Is it too early?
>>>
>>> Regards,
>>> Alejandro
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/bd22a2a7/attachment.html>

From mail at joachim-breitner.de  Fri Dec  4 16:14:05 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 04 Dec 2020 17:14:05 +0100
Subject: [ghc-steering-committee] #380 GHC2021: A plea for GADTs
In-Reply-To: <CAGK9nuopeKDnWoOPzJufTouQ+uf-ZM9poMs2Dmoua_pVP9vbcQ@mail.gmail.com>
References: <CAH6fHQm5E=Y1ka-7-igb0F0k1eZt3E+EvbwoTodUDAZ-Q1DYng@mail.gmail.com>
 <CAGK9nuopeKDnWoOPzJufTouQ+uf-ZM9poMs2Dmoua_pVP9vbcQ@mail.gmail.com>
Message-ID: <7e4f5f8a5c650cb8f98d09547f1a8a8d3b51a2cf.camel@joachim-breitner.de>

Hi,

it seems that GADTs don’t cross my personal uncontroversiality level. I
will change my vote to no as well, following Iavor and SPJ.

Cheers,
Joachim

Am Freitag, den 04.12.2020, 08:02 -0800 schrieb Iavor Diatchki:
> I don't want GADTs to on by default, because pattern matching on them does not work the same as with normal data types (i.e., you often need to have an explicitly type signature, or be aware of GHC type checking algorithm to know when a type signature is not needed).  So I'd like to be able to see explicitly that GADTs might be in play.
> 
> On Fri, Dec 4, 2020 at 5:13 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> > It seems that GADTs are on the fence. There has been a discussion in the main thread.
> > 
> > I, personally, see no reason not to include them: GADTs have their own syntax, and therefore don't interfere with programmers who want to remain oblivious of them.
> > 
> > So I think they deserve their own thread.
> > 
> > 
> > Below the conversation so far
> >  
> > Here is what Alejandro had to say about GADTs
> > > - 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.)
> > > 
> > 
> > Here is Simon PJ
> > > 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 😊.
> > > 
> > 
> >  Here is Tom
> > > 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 :)
> > > 
> > 
> > Here is Simon M
> > > I agree with Simon that we must have GADTs!
> > > 
> > 
> > Here is Richard
> > > > On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at 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!
> > > 
> > 
> > Simon PJ again
> > > 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!
> > > 
> > 
> >  Richard agin
> > > > On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones <simonpj at microsoft.com> 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-ghc-extensions.rst#criteria.
> > > 
> > 
> >  
> > Arnaud
> > > On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae at richarde.dev> 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-ghc-extensions.rst#criteria.
> > > > 
> > > 
> > > 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.
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From iavor.diatchki at gmail.com  Fri Dec  4 16:15:57 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:15:57 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Let's deprecate
	ExistentialQuantification
In-Reply-To: <6ee8a41d01fe0b9b277dc9ab8c10c3051f48283f.camel@joachim-breitner.de>
References: <CAH6fHQmDUp56Ogt+xBcJ0wX5xLquDYHW4CUwi=eFm7tZAWn+rQ@mail.gmail.com>
 <e2de6dfc-5d35-4dcb-bedf-62aed5731d97@www.fastmail.com>
 <c5acde1e-2f12-4f94-91cb-fdf6083b49bd@www.fastmail.com>
 <CAH6fHQnFHKK_+q9WcKABL54oXfFihRr=RsttaioohfQobU7o5w@mail.gmail.com>
 <010f01762e2cb72a-86da0220-7ee4-4a09-b6f6-d4caafc31d75-000000@us-east-2.amazonses.com>
 <CAH6fHQmGj=DbEsde2NH+ueADXqEM+oa0cc2zfZXX40Cc9bcFWA@mail.gmail.com>
 <6ee8a41d01fe0b9b277dc9ab8c10c3051f48283f.camel@joachim-breitner.de>
Message-ID: <CAGK9nur=ZtSkCbv+RYaRRgjys3ao5dN+9rLJdeMddcaf8V=BwA@mail.gmail.com>

I am strongly against deprecating ExistentialQuantification and prefer it
over the GADT notation for non-GADT datatypes.  I find GADT notation nice
when the types of the result change, but I don't think it is great for
normal types (which are the large majority of types I use) for these
reasons:
   - It duplicates the declaration of the types many types, but often it is
not obvious that you have the same type
   - The disconnect between the type variables in the data declaration and
the constructors is confusing, which is why I prefer the GADT from where
you declare the kind of the GADT, but that's quite ugly and verbose.



On Fri, Dec 4, 2020 at 7:25 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Freitag, den 04.12.2020, 15:47 +0100 schrieb Spiwack, Arnaud:
> > I'm just saying: let's _not_ add ExistentialQuantification in GHC2021
> > (because it ought, in my opinion, to be considered deprecated).
>
> I’m convinced!
>
> >  Let's not go into talking about chopping the feature into smaller
> > pieces.
>
> Not for GHC2021! But if GADTs don’t make it this round, we can ask the
> question if ExistentialVariables is a feature worth having on its own,
> of if anyone who wants to use that should just go for GADTs.
>
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/dfdef5c4/attachment.html>

From iavor.diatchki at gmail.com  Fri Dec  4 16:22:41 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Dec 2020 08:22:41 -0800
Subject: [ghc-steering-committee] A plea for BlockArguments
Message-ID: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>

While we are pleading for things, I'd really like to have BlockArguments on
by default, as I use them all the time, and I really don't think that
adding the extension to a module adds much information.

I realize that this is mostly a stylistic issue, and some programmers are
going to prefer to write explicit parens, which is perfectly fine and in
now way incompatible with BlockArguments.

Personally I like the extension because, while it takes a bit of getting
used to, for me it leads to less syntactic noise in the code, which makes
it easier to read and manipulate code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/77981da9/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec  4 16:26:19 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Dec 2020 17:26:19 +0100
Subject: [ghc-steering-committee] A plea for BlockArguments
In-Reply-To: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
References: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
Message-ID: <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>

The baseline question is: what is the consequence for someone who doesn't
use the extension. I've never turned it on, I have no idea of the
consequences. It's been around for some two years already (8.6). Is it
commonly used?

On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> While we are pleading for things, I'd really like to have BlockArguments
> on by default, as I use them all the time, and I really don't think that
> adding the extension to a module adds much information.
>
> I realize that this is mostly a stylistic issue, and some programmers are
> going to prefer to write explicit parens, which is perfectly fine and in
> now way incompatible with BlockArguments.
>
> Personally I like the extension because, while it takes a bit of getting
> used to, for me it leads to less syntactic noise in the code, which makes
> it easier to read and manipulate code.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/2abf790f/attachment.html>

From eric at seidel.io  Fri Dec  4 17:02:43 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 12:02:43 -0500
Subject: [ghc-steering-committee] a plea against ScopedTypeVariables
In-Reply-To: <CAGK9nuoUUxwJ==u6RaPDQkCh=99A=_M3=zY=BcxkX3twSnUgzQ@mail.gmail.com>
References: <010f01762981208f-8aeaa29c-2051-49a1-bd76-6aca3e32afbc-000000@us-east-2.amazonses.com>
 <CANsrgPKzXqdTrUakEGJMyys7d4pmBo4_cLbDqZurrzvU1fJ+HQ@mail.gmail.com>
 <CAH6fHQm_pGo=ARuLnuBKRN6T90G80+XGcewsRJK3Z86aSs1vKw@mail.gmail.com>
 <CAHnFXOsSoO1fzwVd6GOMGjDXWsOWs3C70hx3EhX-BfVsBv8bxg@mail.gmail.com>
 <CAGK9nuoUUxwJ==u6RaPDQkCh=99A=_M3=zY=BcxkX3twSnUgzQ@mail.gmail.com>
Message-ID: <6af08c48-d0e0-43b1-9584-2d25aaaf4e8c@www.fastmail.com>

I've found ScopedTypeVariables to frequently be useful in simple term-level programming as well. It's a fairly common pattern to have some constants associated with a class, which you then access with the combination of ScopedTypeVariables and TypeApplications.

On Fri, Dec 4, 2020, at 11:05, Iavor Diatchki wrote:
> I do think that ScopedTypeVariables are useful, but not so much unless 
> you are doing fancy type level programming (e.g., GADTs, type families, 
> etc).  It is quite easy to do a lot of Haskell without them, so I'd be 
> fine without them in the standard.
> 
> On Fri, Dec 4, 2020 at 5:27 AM Alejandro Serrano Mena <trupill at gmail.com> wrote:
> > I'll reiterate my main point: ScopedTypeVariables is a very useful extension, and one which a lot of people would like to see in the default set. I would be happy to see it removed in a next iteration of the GHC20XX if a better story comes along, but even if we nail the design now, we would need to wait a few years for it to stabilize before inclusion. In the meanwhile, everybody would be wondering why ScopedTypeVariable is not the default.
> > 
> > El vie, 4 dic 2020 a las 14:00, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>) escribió:
> >> I'm still undecided about ScopedTypeVariables (my vote says: maybe), because there are a number of discussions about changing this or that part of the semantics.
> >> 
> >> That being said: I always turn ScopedTypeVariables on. I'd _love_ for it to be the default. The syntax is quirky, but I don't mind adding explicit `forall`-s. Type signatures on patterns, I don't care much about: I use them rarely. But the ability to bind a variable from the type signature inside the term, this is a very essential feature. I'd be just as happy with `\@a`, though.
> >> 
> >> I'm very much on the fence here. Though, this is just the first time around for GHCXXXX, we can afford to be more conservative than on the next rounds. So given that there are doubts around this extension, maybe it's best to leave it out. And have a more ernest discussion for the second round.
> >> 
> >> On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow <marlowsd at gmail.com> wrote:
> >>> That is an infelicity, I agree. However, ScopedTypeVariables fills a massive hole in Haskell, namely the inability to give a type signature to a local function when the type involves type variables bound by an outer scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I understand the concerns.
> >>> 
> >>> Cheers
> >>> Simon
> >>> 
> >>> On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg <rae at richarde.dev> wrote:
> >>>> Hi all,
> >>>> 
> >>>> I'd like to make a small plea against ScopedTypeVariables.
> >>>> 
> >>>> * First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.
> >>>> 
> >>>> * But I very much dislike the way it brings variables into scope from `forall`s. When I write
> >>>> 
> >>>> > f :: forall a. a -> a
> >>>> > f x = (x :: a)
> >>>> 
> >>>> I find it very odd that `a` is brought into scope in the body of f. Compare to
> >>>> 
> >>>> > f :: (forall a. a -> a)
> >>>> > f x = (x :: a)
> >>>> 
> >>>> where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.
> >>>> 
> >>>> * Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.
> >>>> 
> >>>> * I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572523, which re-slices this cake.
> >>>> 
> >>>> Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.
> >>>> 
> >>>> Thanks,
> >>>> Richard
> >>>> _______________________________________________
> >>>> ghc-steering-committee mailing list
> >>>> ghc-steering-committee at haskell.org
> >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From rae at richarde.dev  Fri Dec  4 18:34:07 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 18:34:07 +0000
Subject: [ghc-steering-committee] A plea for BlockArguments
In-Reply-To: <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>
References: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
 <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>
Message-ID: <010f01762f0862f7-9b80aebe-1d7e-44b4-bd6d-72c15d5cd567-000000@us-east-2.amazonses.com>

I almost sent out a plea for BlockArguments, but decided not to overplea. I agree fully with Iavor here.

BlockArguments is a *simplification* over the status quo. Look at the grammars in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification. We see that the new grammar (the second block) effectively has one fewer nonterminal (lexp becomes redundant). Consequently, users no longer have to remember which forms belong in which nonterminal.

One of the arguments against BlockArguments was that the change was so trivial, likely saving fewer characters than writing the extension name would take. But having it on my default makes it much more useful. Indeed, I would advocate (at some appropriate time in the future) for deprecating -XNoBlockArguments.

All that said, I don't use BlockArguments myself, because I find the parentheses a tiny bit helpful. But nothing about this extension means I can't keep doing what I've been doing.

NB: There is a big difference between BlockArguments and the weird precedence around record-update. In `f r { field = new_val }`, we learn that there is a record-update only *after* reading `r`, and so we humans have to go back and re-parse. In the case of the re-associated constructs in -XBlockArguments, there is a keyword herald (counting \ as a keyword), and so no re-parsing is necessary.

Richard

> On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> The baseline question is: what is the consequence for someone who doesn't use the extension. I've never turned it on, I have no idea of the consequences. It's been around for some two years already (8.6). Is it commonly used?
> 
> On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> While we are pleading for things, I'd really like to have BlockArguments on by default, as I use them all the time, and I really don't think that adding the extension to a module adds much information.
> 
> I realize that this is mostly a stylistic issue, and some programmers are going to prefer to write explicit parens, which is perfectly fine and in now way incompatible with BlockArguments.
> 
> Personally I like the extension because, while it takes a bit of getting used to, for me it leads to less syntactic noise in the code, which makes it easier to read and manipulate code.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/1babf70b/attachment-0001.html>

From rae at richarde.dev  Fri Dec  4 18:44:07 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 18:44:07 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <872fec099df8002da39905ea176e9b0ff1a67a67.camel@joachim-breitner.de>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
 <872fec099df8002da39905ea176e9b0ff1a67a67.camel@joachim-breitner.de>
Message-ID: <010f01762f118b72-90121f76-7e07-4d97-b319-335d294334b0-000000@us-east-2.amazonses.com>



> On Dec 4, 2020, at 10:29 AM, Joachim Breitner <mail at joachim-breitner.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/ef04d5d6/attachment.html>

From rae at richarde.dev  Fri Dec  4 18:49:31 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 18:49:31 +0000
Subject: [ghc-steering-committee] a plea for PolyKinds
In-Reply-To: <CAH6fHQnz_wGmbP77z_MVrGNu0P+12DEHQEG9MiCrihfPhyhB4w@mail.gmail.com>
References: <010f01762979f9e4-42c02667-56b0-4445-8371-20b06975e8cf-000000@us-east-2.amazonses.com>
 <CAH6fHQnz_wGmbP77z_MVrGNu0P+12DEHQEG9MiCrihfPhyhB4w@mail.gmail.com>
Message-ID: <010f01762f167d76-9c662d36-43c8-495f-a962-e5643f3de490-000000@us-east-2.amazonses.com>



> On Dec 4, 2020, at 3:18 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Is it even possible while still supporting Haskell2010?

My hunch is "yes". I can imagine trouble with PolyKinds, but each example requires one of NoPolyKinds (in another module), ScopedTypeVariables, or KindSignatures. And each case of trouble is obscure.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/303f326a/attachment.html>

From rae at richarde.dev  Fri Dec  4 19:17:07 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Dec 2020 19:17:07 +0000
Subject: [ghc-steering-committee] Unsaturated type families (#242)
In-Reply-To: <VI1PR83MB0222DA10AF230ECEB80EE9E4ADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com>
 <PR3PR83MB0475233557213B8DEFCDEF8CADFA1@PR3PR83MB0475.EURPRD83.prod.outlook.com>
 <010f01761f8f9a2e-e19f958c-aca0-4b9f-8c16-422110905b74-000000@us-east-2.amazonses.com>
 <CAH6fHQmpNv9-NNCZuEJ5BCNkO_sZ2iE2Y2Hxj1eckjouoLaZgw@mail.gmail.com>
 <73334e5f-e1d3-459b-8ab8-1ff8cdc82c0c@www.fastmail.com>
 <VI1PR83MB0222DA10AF230ECEB80EE9E4ADF21@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <010f01762f2fc18d-a12024ee-2df9-4aa8-9fdf-65151324e992-000000@us-east-2.amazonses.com>

The proposal has been accepted on an experimental basis. I added the following text to the proposal itself during acceptance:

Committee Decision
------------------
The committee has accepted this proposal on an *experimental* basis. This
feature is wholly new to Haskell (and to programming, more generally), and
we will learn more from experience. But we cannot gain the experience without
incorporating and releasing the feature. We thus label it as subject to change.
Changes will be incorporated into this document before they are released.

In particular, the following aspects are subject to change:

* Syntax (especially in light of `Proposal #370 <https://github.com/ghc-proposals/ghc-proposals/pull/370>`_).

* The defaulting rules.

These changes might continue (without prior debate here) even after a release, but
all changes will be made in consultation with the GHC developer team, via debate
at `GitLab <https://gitlab.haskell.org/ghc/ghc/>`_.




Thanks, all!
Richard

> On Dec 3, 2020, at 3:27 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I have written a comment on the GitHub thread
> https://github.com/ghc-proposals/ghc-proposals/pull/242#issuecomment-737551909
> 
> I argue for acceptance, but I suggest that we might want to start distinguishing "experimental proposals" from normal proposals.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Eric Seidel
> |  Sent: 03 December 2020 02:30
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Unsaturated type families (#242)
> |  
> |  Apologies for being slow, I've left a number of questions on GitHub,
> |  mostly asking for clarification on various points.
> |  
> |  I'm also generally in favor of this proposal, though like others I
> |  have concerns around the defaulting strategies. Mine are mostly around
> |  the large number of rules that I'll have to keep in my head if I need
> |  to start caring about matchabilites. But I'd be happy with some sort
> |  of provisional acceptance, subject to resolving the syntax and
> |  defaulting rules later.
> |  
> |  On Wed, Dec 2, 2020, at 10:30, Spiwack, Arnaud wrote:
> |  > Dear all,
> |  >
> |  > I'm a bit worried by the limited response from the committee on this
> |  > proposal. It is a non-trivial proposal, and I think it deserves more
> |  > eyes. So please have a look at them so that we can commit to this
> |  with
> |  > confidence.
> |  >
> |  > /Arnaud
> |  >
> |  > On Tue, Dec 1, 2020 at 7:28 PM Richard Eisenberg <rae at richarde.dev>
> |  wrote:
> |  > > This thread has seen only positive responses, and with no
> |  responses for the past 6 days. I'm thus inclined to accept the
> |  proposal.
> |  > >
> |  > > However, there are open questions around the following points:
> |  > > * the concrete syntax (pending discussion on #370)
> |  > > * defaulting rules (as raised by Alejandro in this thread)
> |  > >
> |  > > Conveniently, these are both listed as Unresolved Questions in the
> |  proposal itself. We need a way of resolving these questions. The
> |  syntax question may become clearer once we know what to do about #370.
> |  The defaulting question is harder. I vote to return to this question
> |  once #378 has settled somewhat -- but even then, it will be hard.
> |  Still, I think we should move forward with accepting the main
> |  proposal, and we can continue to debate the defaulting strategy in a
> |  further thread, perhaps in parallel with reviewing the (already
> |  existing) implementation.
> |  > >
> |  > > I will accept this proposal as written at the end of the week,
> |  barring commentary here (or on GitHub) to stop me.
> |  > >
> |  > > Thanks!
> |  > > Richard
> |  > >
> |  > > > On Nov 25, 2020, at 10:28 AM, Simon Peyton Jones
> |  <simonpj at microsoft.com> wrote:
> |  > > >
> |  > > > I'm on board with unsaturated type families.
> |  > > >
> |  > > > Like Linear Haskell, it's quite a "big" proposal, but accepting
> |  it is compatible with idea of Haskell as a laboratory for exploration.
> |  I think we should flag it as experimental, with the implication that
> |  details are liable to change as we gain experience.
> |  > > >
> |  > > > Like others, I'd like us to converge on #370 before fixing
> |  syntax.
> |  > > >
> |  > > > I don’t have a strong opinion about the defaulting stuff.
> |  > > >
> |  > > > Declaration of interest: I'm a co-author on the paper.
> |  > > >
> |  > > > Simon
> |  > > >
> |  > > > |  -----Original Message-----
> |  > > > |  From: ghc-steering-committee <ghc-steering-committee-
> |  > > > | bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  > > > |  Sent: 20 November 2020 19:36
> |  > > > |  To: Simon Peyton Jones via ghc-steering-committee
> |  > > > | <ghc-steering-  committee at haskell.org>
> |  > > > |  Subject: [ghc-steering-committee] Unsaturated type families
> |  > > > | (#242)
> |  > > > |
> |  > > > |  Hi committee,
> |  > > > |
> |  > > > |  Csongor Kiss has proposed -XUnsaturatedTypeFamilies.
> |  > > > |
> |  > > > |  Proposal:
> |  > > > |
> |  > > > |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> |  > > > | 2Fgith
> |  > > > |  ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type-
> |  > > > |  families%2Fproposals%2F0000-unsaturated-type-
> |  > > > |
> |  > > > |
> |  families.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62
> |  > > > | e3137e
> |  > > > |
> |  > > > |
> |  40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%
> |  > > > | 7C6374
> |  > > > |
> |  14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> |  > > > | joiV2l
> |  > > > |
> |  uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WdLjCp2ReG9
> |  > > > | ZXOjmE
> |  > > > |  Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&amp;reserved=0
> |  > > > |  ICFP'19 paper:
> |  > > > |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> |  > > > |  microsoft.com%2Fen-
> |  > > > |  us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-
> |  type-
> |  > > > |  families-icfp-
> |  > > > |
> |  > > > |
> |  2019.pdf&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e313
> |  > > > | 7e4038
> |  > > > |
> |  > > > |
> |  5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63
> |  > > > | 741497
> |  > > > |
> |  8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> |  > > > | 2luMzI
> |  > > > |
> |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dgowMlsNpH0X9fP
> |  > > > | Ar498F
> |  > > > |  Y9u8xML9n0G1nwvPN4R9HA%3D&amp;reserved=0
> |  > > > |  Discussion:
> |  > > > |
> |  > > > |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> |  > > > | 2Fgith
> |  > > > |  ub.com%2Fghc-proposals%2Fghc-
> |  > > > |
> |  > > > |
> |  proposals%2Fpull%2F242&amp;data=04%7C01%7Csimonpj%40microsoft.co
> |  > > > | m%7Cbd
> |  > > > |
> |  9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db4
> |  > > > | 7%7C1%
> |  > > > |
> |  7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> |  > > > | wMDAiL
> |  > > > |
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C
> |  > > > | 9N0y7l
> |  > > > |  KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&amp;reserved=0
> |  > > > |
> |  > > > |  The central idea is to allow type functions (both type
> |  families
> |  > > > | and  type synonyms) to appear unsaturated. (Currently, all
> |  type
> |  > > > | functions  are required syntactically to be applied to all
> |  > > > | parameters they are  declared with.) This poses a problem for
> |  > > > | type inference, as detailed  in both the proposal and the
> |  paper.
> |  > > > | The key question: if we have (f a  ~ g b), can we conclude (f
> |  ~
> |  > > > | g) and (a ~ b)? Not if either of f or g  is a type function.
> |  > > > | This proposal thus describes a mechanism to  introduce a new
> |  > > > | flavor of arrow, such that we can identify type  functions by
> |  > > > | their kind. Specifically, we have regular types like  Maybe ::
> |  > > > | Type -> @M Type (where the M stands for "matchable"), but
> |  type
> |  > > > | functions like F :: Type -> @U Type (where the U stands for
> |  > > > | "unmatchable"). Unmatchable applications can not be decomposed
> |  during  type inference.
> |  > > > |
> |  > > > |  Much of the proposal is concerned with backward-
> |  compatibility:
> |  > > > | most  users will not want to write @M or @U after each of
> |  their
> |  > > > | arrows, so  the proposal describes ways of defaulting this
> |  > > > | behavior to match
> |  > > > |  (most) programmers' expectations.
> |  > > > |
> |  > > > |  The proposal also includes matchability polymorphism, the
> |  > > > | ability to  abstract over a matchability parameter.
> |  > > > |
> |  > > > |  Pros:
> |  > > > |  + This proposal greatly increases the expressiveness of
> |  > > > | Haskell's type  system.
> |  > > > |  + With this proposal, we can finally do proper functional
> |  > > > | programming  in types, rather than just in terms.
> |  > > > |  + This proposal is a key ingredient toward having dependent
> |  > > > | types, as  + unsaturated functions are commonplace in terms,
> |  and
> |  > > > | thus should also  be supported in types. (Allowing unsaturated
> |  > > > | functions in types was a  key difference between Adam Gundry's
> |  > > > | proposal for dependent types
> |  > > > |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> |  > > > | 2Fadam
> |  > > > |
> |  .gundry.co.uk%2Fpub%2Fthesis%2F&amp;data=04%7C01%7Csimonpj%40mic
> |  > > > | rosoft
> |  > > > |
> |  > > > |
> |  .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d
> |  > > > | 7cd011
> |  > > > |
> |  db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> |  > > > | oiMC4w
> |  > > > |
> |  LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> |  > > > | p;sdat
> |  > > > |
> |  a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&amp;reserved=
> |  > > > | 0,  which requires a notion of a subset of the type and term
> |  > > > | languages  shared in common, and mine, which makes no
> |  > > > | distinction between terms  and types.) There is a prototype
> |  > > > | implementation.
> |  > > > |  + The ideas are backed up by peer-reviewed research.
> |  > > > |  + Despite focusing on type families, this work applies
> |  equally
> |  > > > | to  ordinary functions which might be used in types once we
> |  have
> |  > > > | stronger  support for dependent types.
> |  > > > |
> |  > > > |  Cons:
> |  > > > |  - This adds a new dimension of complexity to our kind system,
> |  > > > | by  separating out matchable and unmatchable arrows.
> |  > > > |  - The rules for defaulting appear convenient in practice, but
> |  > > > | are  somewhat arbitrary.
> |  > > > |  - The rules for defaulting care about context -- does an
> |  arrow
> |  > > > | appear  in the type of a term or the type of a type? These
> |  rules
> |  > > > | thus go  against the spirit of #378, which advocates for not
> |  > > > | accepting features  that distinguish between types and terms.
> |  > > > |
> |  > > > |  Recommendation: With reservations, I recommend acceptance. I
> |  > > > | think  that the power to use higher-order programming should
> |  not
> |  > > > | be  restricted to terms, and allowing unsaturated functions at
> |  > > > | compile  time is necessary in order to have convenient
> |  dependent types.
> |  > > > |  However, I am concerned about the extra complexity of
> |  > > > | matchability. A  key open question for me is how much
> |  > > > | matchability is apparent to users
> |  > > > |  -- even ones using some higher-order type-level programming.
> |  If
> |  > > > | matchability is pervasive, then I would lean against. But my
> |  > > > | expectation is that matchability fades into the background --
> |  > > > | much  like levity polymorphism (unless you want it).
> |  > > > |
> |  > > > |  Open question: What to do about syntax? The proposed syntax
> |  is
> |  > > > | sensible. However, #370 suggests an alternative syntax that
> |  > > > | might be  more forward-thinking.
> |  > > > |
> |  > > > |  Richard
> |  > > > |  _______________________________________________
> |  > > > |  ghc-steering-committee mailing list
> |  > > > | ghc-steering-committee at haskell.org
> |  > > > |
> |  > > > |
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> |  > > > | 2Fmail
> |  > > > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  > > > |
> |  > > > |
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e31
> |  > > > | 37e403
> |  > > > |
> |  > > > |
> |  85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6
> |  > > > | 374149
> |  > > > |
> |  78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> |  > > > | V2luMz
> |  > > > |
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cIlDCT4r8C8Yc0
> |  > > > | %2BOib
> |  > > > |  Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&amp;reserved=0
> |  > >
> |  > > _______________________________________________
> |  > > ghc-steering-committee mailing list
> |  > > ghc-steering-committee at haskell.org
> |  > >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  > > il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committ
> |  > >
> |  ee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C692997bb67394e8cab4f
> |  > >
> |  08d897335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374255946
> |  > >
> |  59710772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> |  > >
> |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6s
> |  > > imMc%2Ffai00Qi9%2B8OIsmGPQp0%3D&amp;reserved=0
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at 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%7C692997bb67394e8cab4f08d897
> |  >
> |  335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425594659710772
> |  >
> |  %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> |  >
> |  k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6simMc%2Ffai00
> |  > Qi9%2B8OIsmGPQp0%3D&amp;reserved=0
> |  >
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C692997bb67394e8
> |  cab4f08d897335e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374255
> |  94659710772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IBnpaWeHnKRh6p0Sv6si
> |  mMc%2Ffai00Qi9%2B8OIsmGPQp0%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Sat Dec  5 00:57:01 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 19:57:01 -0500
Subject: [ghc-steering-committee] A plea for BlockArguments
In-Reply-To: <010f01762f0862f7-9b80aebe-1d7e-44b4-bd6d-72c15d5cd567-000000@us-east-2.amazonses.com>
References: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
 <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>
 <010f01762f0862f7-9b80aebe-1d7e-44b4-bd6d-72c15d5cd567-000000@us-east-2.amazonses.com>
Message-ID: <2f9414d5-96ee-4304-8540-af89a41bee23@www.fastmail.com>

I really like the idea of BlockArguments, but I haven't had enough of an opportunity to experiment with it to see how it feels in practice, so I marked it as "maybe". I'd be happy to hear from people who do have the experience though.

On Fri, Dec 4, 2020, at 13:34, Richard Eisenberg wrote:
> I almost sent out a plea for BlockArguments, but decided not to 
> overplea. I agree fully with Iavor here.
> 
> BlockArguments is a *simplification* over the status quo. Look at the 
> grammars in 
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification. We see that the new grammar (the second block) effectively has one fewer nonterminal (lexp becomes redundant). Consequently, users no longer have to remember which forms belong in which nonterminal.
> 
> One of the arguments against BlockArguments was that the change was so 
> trivial, likely saving fewer characters than writing the extension name 
> would take. But having it on my default makes it much more useful. 
> Indeed, I would advocate (at some appropriate time in the future) for 
> deprecating -XNoBlockArguments.
> 
> All that said, I don't use BlockArguments myself, because I find the 
> parentheses a tiny bit helpful. But nothing about this extension means 
> I can't keep doing what I've been doing.
> 
> NB: There is a big difference between BlockArguments and the weird 
> precedence around record-update. In `f r { field = new_val }`, we learn 
> that there is a record-update only *after* reading `r`, and so we 
> humans have to go back and re-parse. In the case of the re-associated 
> constructs in -XBlockArguments, there is a keyword herald (counting \ 
> as a keyword), and so no re-parsing is necessary.
> 
> Richard
> 
> > On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> > 
> > The baseline question is: what is the consequence for someone who doesn't use the extension. I've never turned it on, I have no idea of the consequences. It's been around for some two years already (8.6). Is it commonly used?
> > 
> > On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> >> While we are pleading for things, I'd really like to have BlockArguments on by default, as I use them all the time, and I really don't think that adding the extension to a module adds much information.
> >> 
> >> I realize that this is mostly a stylistic issue, and some programmers are going to prefer to write explicit parens, which is perfectly fine and in now way incompatible with BlockArguments.
> >> 
> >> Personally I like the extension because, while it takes a bit of getting used to, for me it leads to less syntactic noise in the code, which makes it easier to read and manipulate code.
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From eric at seidel.io  Sat Dec  5 01:04:13 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 04 Dec 2020 20:04:13 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <010f01762f118b72-90121f76-7e07-4d97-b319-335d294334b0-000000@us-east-2.amazonses.com>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
 <872fec099df8002da39905ea176e9b0ff1a67a67.camel@joachim-breitner.de>
 <010f01762f118b72-90121f76-7e07-4d97-b319-335d294334b0-000000@us-east-2.amazonses.com>
Message-ID: <177d3aea-45c7-4d57-b954-e1201d0c362d@www.fastmail.com>

Here are my updated votes, I changed:

> StarIsType: yes (convinced by Joachim not to rock the boat too much at first)
> DerivingVia: no (convinced by Arnaud that it's not mature enough yet)

---

## 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
StarIsType: 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
  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
GeneralisedNewtypeDeriving: yes
StandaloneDeriving: yes

DerivingStrategies: maybe

DeriveAnyClass: no
DerivingVia: 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 Fri, Dec 4, 2020, at 13:44, Richard Eisenberg wrote:
> 
> 
> > On Dec 4, 2020, at 10:29 AM, Joachim Breitner <mail at joachim-breitner.de> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From marlowsd at gmail.com  Sat Dec  5 12:00:35 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 5 Dec 2020 12:00:35 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
Message-ID: <CANsrgPJvp5BxTBS=MMV-gVgXMCWu_Yz-ydGBGM=M+X7=Ve73QA@mail.gmail.com>

On Fri, 4 Dec 2020 at 13:25, Eric Seidel <eric at seidel.io> wrote:

> On Fri, Dec 4, 2020, at 07:41, Joachim Breitner wrote:
> > 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.
>
> 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.
>

At FB we build everything with Buck. It doesn't use Cabal to build Haskell
code, but we do use a pre-defined set of extensions for all our Haskell
code, so we would be insulated from any changes to the default set of
extensions.

My guess is that GHC's "default language" mode is rarely used in practice,
despite it being the default. We can change it without much fallout.

Cheers
Simon

> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201205/0279875a/attachment.html>

From marlowsd at gmail.com  Sat Dec  5 12:10:45 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 5 Dec 2020 12:10:45 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Current status
In-Reply-To: <177d3aea-45c7-4d57-b954-e1201d0c362d@www.fastmail.com>
References: <3DC7B510-952F-48D3-B754-1E46EE5CE5CB@live.co.uk>
 <63CB4BD7-1F07-481D-B6CE-D6713A39E007@seidel.io>
 <077fdcd40ee6d9bf8b467e3c6596f393fdf45229.camel@joachim-breitner.de>
 <87e0c933-47d2-4bbb-a464-73c3ad62eaa4@www.fastmail.com>
 <872fec099df8002da39905ea176e9b0ff1a67a67.camel@joachim-breitner.de>
 <010f01762f118b72-90121f76-7e07-4d97-b319-335d294334b0-000000@us-east-2.amazonses.com>
 <177d3aea-45c7-4d57-b954-e1201d0c362d@www.fastmail.com>
Message-ID: <CANsrgPKwk4idSJbP4UD3D30SkPkLv7eZvSsby229M1r5LVze_g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201205/8deec2ab/attachment.html>

From marlowsd at gmail.com  Sat Dec  5 12:20:00 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 5 Dec 2020 12:20:00 +0000
Subject: [ghc-steering-committee] A plea for BlockArguments
In-Reply-To: <2f9414d5-96ee-4304-8540-af89a41bee23@www.fastmail.com>
References: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
 <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>
 <010f01762f0862f7-9b80aebe-1d7e-44b4-bd6d-72c15d5cd567-000000@us-east-2.amazonses.com>
 <2f9414d5-96ee-4304-8540-af89a41bee23@www.fastmail.com>
Message-ID: <CANsrgP+nQ7AvZzQOqrqrNOSZTVr9sf8gQArktncrDrV2ofmQ9g@mail.gmail.com>

I'm in the same position as Eric: it seems plausible but I haven't used it
- it was added in 8.6.1, and doesn't even exist in the version of GHC we
are using at FB! So I haven't developed a sense for how well it works in
practice. Perhaps we should punt on this until GHC2022 given that it's so
new, though?

Cheers
Simon

On Sat, 5 Dec 2020 at 00:57, Eric Seidel <eric at seidel.io> wrote:

> I really like the idea of BlockArguments, but I haven't had enough of an
> opportunity to experiment with it to see how it feels in practice, so I
> marked it as "maybe". I'd be happy to hear from people who do have the
> experience though.
>
> On Fri, Dec 4, 2020, at 13:34, Richard Eisenberg wrote:
> > I almost sent out a plea for BlockArguments, but decided not to
> > overplea. I agree fully with Iavor here.
> >
> > BlockArguments is a *simplification* over the status quo. Look at the
> > grammars in
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification.
> We see that the new grammar (the second block) effectively has one fewer
> nonterminal (lexp becomes redundant). Consequently, users no longer have to
> remember which forms belong in which nonterminal.
> >
> > One of the arguments against BlockArguments was that the change was so
> > trivial, likely saving fewer characters than writing the extension name
> > would take. But having it on my default makes it much more useful.
> > Indeed, I would advocate (at some appropriate time in the future) for
> > deprecating -XNoBlockArguments.
> >
> > All that said, I don't use BlockArguments myself, because I find the
> > parentheses a tiny bit helpful. But nothing about this extension means
> > I can't keep doing what I've been doing.
> >
> > NB: There is a big difference between BlockArguments and the weird
> > precedence around record-update. In `f r { field = new_val }`, we learn
> > that there is a record-update only *after* reading `r`, and so we
> > humans have to go back and re-parse. In the case of the re-associated
> > constructs in -XBlockArguments, there is a keyword herald (counting \
> > as a keyword), and so no re-parsing is necessary.
> >
> > Richard
> >
> > > On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> > >
> > > The baseline question is: what is the consequence for someone who
> doesn't use the extension. I've never turned it on, I have no idea of the
> consequences. It's been around for some two years already (8.6). Is it
> commonly used?
> > >
> > > On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <
> iavor.diatchki at gmail.com> wrote:
> > >> While we are pleading for things, I'd really like to have
> BlockArguments on by default, as I use them all the time, and I really
> don't think that adding the extension to a module adds much information.
> > >>
> > >> I realize that this is mostly a stylistic issue, and some programmers
> are going to prefer to write explicit parens, which is perfectly fine and
> in now way incompatible with BlockArguments.
> > >>
> > >> Personally I like the extension because, while it takes a bit of
> getting used to, for me it leads to less syntactic noise in the code, which
> makes it easier to read and manipulate code.
> > >> _______________________________________________
> > >> ghc-steering-committee mailing list
> > >> ghc-steering-committee at haskell.org
> > >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201205/5cefa3c5/attachment.html>

From mail at joachim-breitner.de  Sat Dec  5 15:40:18 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 Dec 2020 16:40:18 +0100
Subject: [ghc-steering-committee] A plea for BlockArguments
In-Reply-To: <CANsrgP+nQ7AvZzQOqrqrNOSZTVr9sf8gQArktncrDrV2ofmQ9g@mail.gmail.com>
References: <CAGK9nupCoopvj97O40MXC2w0aCN1cgRCh8mMyLWFBVLZp3XbJw@mail.gmail.com>
 <CAH6fHQkgmt2FicNZEt0TQcn28YfTnQibH9UPRNMSZtDOAZ1Y=Q@mail.gmail.com>
 <010f01762f0862f7-9b80aebe-1d7e-44b4-bd6d-72c15d5cd567-000000@us-east-2.amazonses.com>
 <2f9414d5-96ee-4304-8540-af89a41bee23@www.fastmail.com>
 <CANsrgP+nQ7AvZzQOqrqrNOSZTVr9sf8gQArktncrDrV2ofmQ9g@mail.gmail.com>
Message-ID: <436047afbcd4f9ea86ed284fed2d57c232e9ba38.camel@joachim-breitner.de>

Hi,

Am Samstag, den 05.12.2020, 12:20 +0000 schrieb Simon Marlow:
> So I haven't developed a sense for how well it works in practice.
> Perhaps we should punt on this until GHC2022 given that it's so new,
> though?

me neither. It’s a bit of an odd situation: I was advocating for it
when it went through the process, and I am still looking forward to it.
But as long as I have to add the extension to the file before using it,
I’m more inclined to throw in to $ and keep on coding. So I have not
used it a lot yet, because it's not on by default… so maybe I should
make sure it’s on eventually ;-)

But yes, maybe better to keep some nice cookies in the jar for GHC2022…
Plus, not everybody will be 100% happy about this being on by default.

Cheers,
Joachim

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



From trupill at gmail.com  Sat Dec  5 20:42:22 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 5 Dec 2020 20:42:22 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <8D9C68DD-0F3C-45AB-96A5-03C2251BE12C@seidel.io>
References: <f3b258fbd4929e78ec993305539fd192572d0296.camel@joachim-breitner.de>
 <8D9C68DD-0F3C-45AB-96A5-03C2251BE12C@seidel.io>
Message-ID: <CAHnFXOtOqcC+mrDpoEu-TrFaov5c11d0AqrJRRYU=LOLjEb84g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201205/7531b928/attachment.html>

From mail at joachim-breitner.de  Sun Dec  6 22:32:27 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 06 Dec 2020 23:32:27 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
Message-ID: <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>

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



From iavor.diatchki at gmail.com  Mon Dec  7 04:57:43 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 6 Dec 2020 20:57:43 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
Message-ID: <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>

Just for the record, I voted "yes" on view patterns... :)

On Sun, Dec 6, 2020 at 2:32 PM Joachim Breitner <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201206/7e96908c/attachment-0001.html>

From iavor.diatchki at gmail.com  Mon Dec  7 05:20:15 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 6 Dec 2020 21:20:15 -0800
Subject: [ghc-steering-committee] Updated GHC 20201
Message-ID: <CAGK9nuqtafbftv-Y8osLeDbj=bxs-JcZ_ubhhrR8pticjT6Lsg@mail.gmail.com>

Hello,

These are my updated votes.  I marked the changes with CHANGED, so you
could search for those to see a delta.

-Iavor


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

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

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


Notation
========

BlockArguments: yes
-- ^ I use this all the time.

MultiWayIf: yes
-- ^ This is nice on occasion, and it does not seem to conflict with
-- anything.  Certainly nicer than the alternative `case () of _ | ... `:

LambdaCase: no
-- ^ CHANGED from maybe.  Simon PJ makes a good point that alternatives are
under consideration, so it should not be on yet.

-- | The various literal notations seem useful when you need them
-- and don't conflict with anything.
BinaryLiterals: yes
HexFloatLiterals: yes
NumericUnderscores: yes
NumDecimals: maybe
-- ^ | Not too sure about this last one, I've never used, but it
-- I could see it being useful on occasion.

OverloadedStrings: maybe
-- ^ | CHANGED from yes.  I use this a lot, and would be OK with it being
on all the time, but if others would rather not have it on, it's not a big
deal to turn on when needed.

OverloadedLists: maybe
-- | ^ I've never used this, but I could see it potentially being useful.

OverloadedLabels: no
-- | ^ This one seems for experimenting with various new features
-- (e.g., record selectors), so it seems reasonable to turn it on only
-- when it is needed.

EmptyCase: maybe
-- ^ Seems like a nicer notation for forcing `Void` values.
-- I agree that it is odd that it is strict.  OTOH, it'd be quite useless
-- if it was lazy, so I could go either way.

-- | I haven't really used any of those, so I could go either way:
PostfixOperators: yes
-- CHANGED from maybe.  Convinced by Simon M.

LexicalNegation: maybe
UnicodeSyntax: yes
-- CHANGED from maybe.  Convinced by Joachim.

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

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

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

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

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

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

Arrows: no
-- ^ It's not used a lot, not terribly useful and overall feels "clunky".

ApplicativeDo: maybe
-- ^ I think the core of this extension is really useful,
-- but I would prefer a simpler syntactic version of it,
-- without the various transformations assuming that some laws hold.

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

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

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

RebindableSyntax: no
-- ^ This is a very special case thing

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


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

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

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

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

RoleAnnotations: no
-- ^ This only makes sense with `GeneralisedNewtypeDeriving` which
-- I don't think should be on by default.

StrictData: no
-- ^ This is very unHaskell :)

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

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


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

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

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

NoPatternGuards: no
-- ^ Conflicts with Haskell2010

NPlusKPatterns: no
-- ^ Conflicts with Haskell2010


Records
=======

-- | I find these two very useful when working with records,
-- especially large ones, and declaring the extension really adds no
-- information:
NamedFieldPuns: yes
RecordWildCards: yes

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

Deriving
=======

-- | Declaring these as extensions explicitly adds very little information.
DeriveGeneric: yes
DeriveLift: yes
DeriveDataTypeable: yes

EmptyDataDeriving: yes
-- ^ Useful for consistency

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


-- | I think the rest of the deriving extensions are not particularly
orthogonal
at the moment, so I don't think we should have them on by default, at least
not yet, even though I find some of them quite useful.

DeriveFunctor: yes
DeriveFoldable: yes
DeriveTraversable: yes
-- ^ The 3 above CHANGED from no.   I was concerned about
conflicting deriving strategies, but I guess these probably always make
sense.

DerivingStrategies: no
DerivingVia: no
GeneralisedNewtypeDeriving: no
DeriveAnyClass: no


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

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

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

ConstraintKinds: yes
-- ^ CHANGED from maybe. These seem like a very nice fit with the rest of
the kind system,
-- so I think we can enable them.  The reason I wrote `maybe` is due to
-- the confusion between constraints and tuples.

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

-- | I haven't really used these much, so I don't have a strong opinion:
ConstrainedClassMethods: maybe
DefaultSignatures: maybe
InstanceSigs: maybe
ExtendedDefaultRules: no
CHANGED from maybe.  This is mostly for GHCi.

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

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

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

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

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

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

Types
=====

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

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

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

-- | These two go together and seem quite useful, especially when writing
-- local type signatures.
ScopedTypeVariables: maybe
ExplicitForAll: maybe
CHANGED from yes to maybe.  Personally, I wouldn't mind if this was on all
the time, but Richard seems to prefer that it is not, so I could go either
way.

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

ImpredicativeTypes: no
-- ^ These are being currently redesigned, so not ready.

MonoLocalBinds: maybe
-- ^ I don't know if this one is on by default or not already...

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

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

LinearTypes: no
-- ^ Too new to be standardized

TypeApplications: no
-- ^ This one is quite useful, bit it seems that its design and how many
users
-- understand it don't match, so maybe there is more work to be done.

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


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

ForeignFunctionInterface: yes
CApiFFI: yes
CHANGED from no.  FFI is part of Haskell 2010, and so should be on by
default.  If the FFI is on, then it makes a lot of sense to have CApiFFI on
too.


GHCForeignImportPrim: no
InterruptibleFFI: no
UnliftedFFITypes: no
StaticPointers: no


Low Level
=========

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

UnboxedSums: no
UnboxedTuples: no
MagicHash: no
UnliftedNewtypes: yes
CHANGED from no.  This one just makes sense, and while it is not terribly
useful without the other extensions (as there is no way to actually write
an unboxed type in the first place), it would be one fewer extension to
write if one want to use low level stuff

Macros
======

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


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

TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no


Other
=====

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


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

Obsolete/Deprecated
===================
CUSKs: no
TypeInType: no
MonadFailDesugaring: maybe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201206/74942be9/attachment.html>

From mail at joachim-breitner.de  Mon Dec  7 10:00:23 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Dec 2020 11:00:23 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
Message-ID: <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>

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



From simonpj at microsoft.com  Mon Dec  7 10:07:21 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2020 10:07:21 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
 <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 07 December 2020 10:00
|  To: ghc-steering-committee at 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 at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C6c6504d2ad7743e
|  9cc1908d89a96f377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374293
|  20415242213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zwUBdR2NKxtsr7qxL3hC
|  uYKwHI8StkX9FNDnvzOopDg%3D&amp;reserved=0

From mail at joachim-breitner.de  Mon Dec  7 10:31:00 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Dec 2020 11:31:00 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
 <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
 <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <f036804eb49703ca5b46b9560d8ba9458ab191f3.camel@joachim-breitner.de>

Hi,

Am Montag, den 07.12.2020, 10:07 +0000 schrieb Simon Peyton Jones via
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.


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

Cheers,
Joachim

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



From iavor.diatchki at gmail.com  Mon Dec  7 16:36:41 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 7 Dec 2020 08:36:41 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <f036804eb49703ca5b46b9560d8ba9458ab191f3.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
 <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
 <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <f036804eb49703ca5b46b9560d8ba9458ab191f3.camel@joachim-breitner.de>
Message-ID: <CAGK9nuoFUhUDH0udp2m3SQmh5SBd4LYJb_chGU9R4=Nzh66-+w@mail.gmail.com>

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 <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, den 07.12.2020, 10:07 +0000 schrieb Simon Peyton Jones via
> 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.
>
>
> you pleat against it, so I changed my vote from yes to no.
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/27528d75/attachment.html>

From mail at joachim-breitner.de  Mon Dec  7 16:42:09 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Dec 2020 17:42:09 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <CAGK9nuoFUhUDH0udp2m3SQmh5SBd4LYJb_chGU9R4=Nzh66-+w@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
 <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
 <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <f036804eb49703ca5b46b9560d8ba9458ab191f3.camel@joachim-breitner.de>
 <CAGK9nuoFUhUDH0udp2m3SQmh5SBd4LYJb_chGU9R4=Nzh66-+w@mail.gmail.com>
Message-ID: <9988e1ae9ace925ef8d817986c345c3bac8ff027.camel@joachim-breitner.de>

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


From iavor.diatchki at gmail.com  Mon Dec  7 17:25:54 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 7 Dec 2020 09:25:54 -0800
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <9988e1ae9ace925ef8d817986c345c3bac8ff027.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
 <CAGK9nur_a+kqmFdQaxLNmj6aUX4h-CGftCHW+5=Qkyvej_pPBg@mail.gmail.com>
 <f60ff75e8e1ac32c3e04e9259cd863860e4d6b50.camel@joachim-breitner.de>
 <VI1PR83MB022223E94C5231E400D8A86CADCE1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <f036804eb49703ca5b46b9560d8ba9458ab191f3.camel@joachim-breitner.de>
 <CAGK9nuoFUhUDH0udp2m3SQmh5SBd4LYJb_chGU9R4=Nzh66-+w@mail.gmail.com>
 <9988e1ae9ace925ef8d817986c345c3bac8ff027.camel@joachim-breitner.de>
Message-ID: <CAGK9nurBHMt6q0OwzPRSvB=b5Fm3z2+TtmhkECr=2wzds76Frw@mail.gmail.com>

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 <mail at joachim-breitner.de>
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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/8d165a31/attachment.html>

From iavor.diatchki at gmail.com  Mon Dec  7 17:28:02 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 7 Dec 2020 09:28:02 -0800
Subject: [ghc-steering-committee] Fwd: Updated GHC 20201
In-Reply-To: <CAGK9nuqtafbftv-Y8osLeDbj=bxs-JcZ_ubhhrR8pticjT6Lsg@mail.gmail.com>
References: <CAGK9nuqtafbftv-Y8osLeDbj=bxs-JcZ_ubhhrR8pticjT6Lsg@mail.gmail.com>
Message-ID: <CAGK9nuokGj4jHKcrpBq6E-+yu6CS2X8EGzRRb3UCqO+F7XBUUQ@mail.gmail.com>

Hello,

Another update to my vote, to do with ViewPatterns.
-Iavor


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

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

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


Notation
========

BlockArguments: yes
-- ^ I use this all the time.

MultiWayIf: yes
-- ^ This is nice on occasion, and it does not seem to conflict with
-- anything.  Certainly nicer than the alternative `case () of _ | ... `:

LambdaCase: no
-- ^ CHANGED from maybe.  Simon PJ makes a good point that alternatives are
under consideration, so it should not be on yet.

-- | The various literal notations seem useful when you need them
-- and don't conflict with anything.
BinaryLiterals: yes
HexFloatLiterals: yes
NumericUnderscores: yes
NumDecimals: maybe
-- ^ | Not too sure about this last one, I've never used, but it
-- I could see it being useful on occasion.

OverloadedStrings: maybe
-- ^ | CHANGED from yes.  I use this a lot, and would be OK with it being
on all the time, but if others would rather not have it on, it's not a big
deal to turn on when needed.

OverloadedLists: maybe
-- | ^ I've never used this, but I could see it potentially being useful.

OverloadedLabels: no
-- | ^ This one seems for experimenting with various new features
-- (e.g., record selectors), so it seems reasonable to turn it on only
-- when it is needed.

EmptyCase: maybe
-- ^ Seems like a nicer notation for forcing `Void` values.
-- I agree that it is odd that it is strict.  OTOH, it'd be quite useless
-- if it was lazy, so I could go either way.

-- | I haven't really used any of those, so I could go either way:
PostfixOperators: yes
-- CHANGED from maybe.  Convinced by Simon M.

LexicalNegation: maybe
UnicodeSyntax: yes
-- CHANGED from maybe.  Convinced by Joachim.

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

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

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

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

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

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

Arrows: no
-- ^ It's not used a lot, not terribly useful and overall feels "clunky".

ApplicativeDo: maybe
-- ^ I think the core of this extension is really useful,
-- but I would prefer a simpler syntactic version of it,
-- without the various transformations assuming that some laws hold.

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

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

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

RebindableSyntax: no
-- ^ This is a very special case thing

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


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

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

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

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

RoleAnnotations: no
-- ^ This only makes sense with `GeneralisedNewtypeDeriving` which
-- I don't think should be on by default.

StrictData: no
-- ^ This is very unHaskell :)

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

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


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

ViewPatterns: no
-- ^ CHANGES form yes. Useful on occasion, but seems that there might be
better designs aroudn
-- (e.g. guarded patterns)

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

NoPatternGuards: no
-- ^ Conflicts with Haskell2010

NPlusKPatterns: no
-- ^ Conflicts with Haskell2010


Records
=======

-- | I find these two very useful when working with records,
-- especially large ones, and declaring the extension really adds no
-- information:
NamedFieldPuns: yes
RecordWildCards: yes

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

Deriving
=======

-- | Declaring these as extensions explicitly adds very little information.
DeriveGeneric: yes
DeriveLift: yes
DeriveDataTypeable: yes

EmptyDataDeriving: yes
-- ^ Useful for consistency

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


-- | I think the rest of the deriving extensions are not particularly
orthogonal
at the moment, so I don't think we should have them on by default, at least
not yet, even though I find some of them quite useful.

DeriveFunctor: yes
DeriveFoldable: yes
DeriveTraversable: yes
-- ^ The 3 above CHANGED from no.   I was concerned about
conflicting deriving strategies, but I guess these probably always make
sense.

DerivingStrategies: no
DerivingVia: no
GeneralisedNewtypeDeriving: no
DeriveAnyClass: no


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

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

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

ConstraintKinds: yes
-- ^ CHANGED from maybe. These seem like a very nice fit with the rest of
the kind system,
-- so I think we can enable them.  The reason I wrote `maybe` is due to
-- the confusion between constraints and tuples.

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

-- | I haven't really used these much, so I don't have a strong opinion:
ConstrainedClassMethods: maybe
DefaultSignatures: maybe
InstanceSigs: maybe
ExtendedDefaultRules: no
CHANGED from maybe.  This is mostly for GHCi.

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

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

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

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

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

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

Types
=====

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

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

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

-- | These two go together and seem quite useful, especially when writing
-- local type signatures.
ScopedTypeVariables: maybe
ExplicitForAll: maybe
CHANGED from yes to maybe.  Personally, I wouldn't mind if this was on all
the time, but Richard seems to prefer that it is not, so I could go either
way.

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

ImpredicativeTypes: no
-- ^ These are being currently redesigned, so not ready.

MonoLocalBinds: maybe
-- ^ I don't know if this one is on by default or not already...

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

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

LinearTypes: no
-- ^ Too new to be standardized

TypeApplications: no
-- ^ This one is quite useful, bit it seems that its design and how many
users
-- understand it don't match, so maybe there is more work to be done.

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


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

ForeignFunctionInterface: yes
CApiFFI: yes
CHANGED from no.  FFI is part of Haskell 2010, and so should be on by
default.  If the FFI is on, then it makes a lot of sense to have CApiFFI on
too.


GHCForeignImportPrim: no
InterruptibleFFI: no
UnliftedFFITypes: no
StaticPointers: no


Low Level
=========

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

UnboxedSums: no
UnboxedTuples: no
MagicHash: no
UnliftedNewtypes: yes
CHANGED from no.  This one just makes sense, and while it is not terribly
useful without the other extensions (as there is no way to actually write
an unboxed type in the first place), it would be one fewer extension to
write if one want to use low level stuff

Macros
======

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


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

TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no


Other
=====

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


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

Obsolete/Deprecated
===================
CUSKs: no
TypeInType: no
MonadFailDesugaring: maybe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/d2adf4a8/attachment-0001.html>

From mail at joachim-breitner.de  Mon Dec  7 18:17:17 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Dec 2020 19:17:17 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Third status update
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>

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-ghc2021.rst#data
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From trupill at gmail.com  Mon Dec  7 20:16:36 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 7 Dec 2020 21:16:36 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAHnFXOtOqcC+mrDpoEu-TrFaov5c11d0AqrJRRYU=LOLjEb84g@mail.gmail.com>
References: <f3b258fbd4929e78ec993305539fd192572d0296.camel@joachim-breitner.de>
 <8D9C68DD-0F3C-45AB-96A5-03C2251BE12C@seidel.io>
 <CAHnFXOtOqcC+mrDpoEu-TrFaov5c11d0AqrJRRYU=LOLjEb84g@mail.gmail.com>
Message-ID: <CAHnFXOu4d8f-oSGPDC0FgSmW_CgxQMQkcx90Arq98gcZFLCWrw@mail.gmail.com>

 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 <trupill at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/75b2668d/attachment-0001.html>

From trupill at gmail.com  Mon Dec  7 20:16:43 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 7 Dec 2020 21:16:43 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Third status update
In-Reply-To: <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
Message-ID: <CAHnFXOtZCTdo_f-AT5So9sNpjoRKzHkb4JMQRwjb+MPaqjsB=w@mail.gmail.com>

 Dear all,
I would like to raise a few points with respect to some extensions:
- What should we do with those which are superseded? I voted ‘yes’ to
NullaryTypeClasses because it’s implied by MultiParamTypeClasses [
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-NullaryTypeClasses].
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.
- ‘MonadFailDesugaring’ is enabled by default since 8.6.1 [
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-MonadFailDesugaring].
We could keep the status quo, and say that the extension is not part of
GHC2021, but it’s enabled by default in GHC; but that seems like a weird
outcome to me.

Regards,
Alejandro

On 7 Dec 2020 at 19:17:17, Joachim Breitner <mail at joachim-breitner.de>
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-ghc2021.rst#data
> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/fbe37dca/attachment.html>

From trupill at gmail.com  Mon Dec  7 20:25:54 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 7 Dec 2020 21:25:54 +0100
Subject: [ghc-steering-committee] GHC2021: a final plea for
	ScopedTypeVariables
Message-ID: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>

Dear all,
I’ll try once again (this is the last one, I’ll promise) to convince the
Committee of including ScopedTypeVariables as part of GHC2021. It has been
with us for a long time — so their problems seem well understood — and the
community seems to want it as part of this new “language version” — which
means that people are really using it.

Most of the criticisms are around the fact the the current manifestation is
not ideal, something I agree with. I would say in this case we should not
let perfect be the enemy of good: if during the years, once types in
patterns or Dependent Haskell extensions require this, the scoping
mechanism needs to change, we can do it. But as of now, ScopedTypeVariables
is a very important piece in the flavour of Haskell in main usage (given
its mainstream acceptance).

forall (member :: Committee). Regards -> member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201207/8c053798/attachment.html>

From mail at joachim-breitner.de  Mon Dec  7 20:36:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 07 Dec 2020 21:36:59 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Implications between
 extensions
In-Reply-To: <CAHnFXOtZCTdo_f-AT5So9sNpjoRKzHkb4JMQRwjb+MPaqjsB=w@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
 <CAHnFXOtZCTdo_f-AT5So9sNpjoRKzHkb4JMQRwjb+MPaqjsB=w@mail.gmail.com>
Message-ID: <4ad97604a5b1ada9dd598eb1134779c93c11ad25.camel@joachim-breitner.de>

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



From eric at seidel.io  Mon Dec  7 20:45:36 2020
From: eric at seidel.io (Eric Seidel)
Date: Mon, 07 Dec 2020 15:45:36 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23380_GHC2021=3A_Implications?=
 =?utf-8?q?_between_extensions?=
In-Reply-To: <4ad97604a5b1ada9dd598eb1134779c93c11ad25.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
 <CAHnFXOtZCTdo_f-AT5So9sNpjoRKzHkb4JMQRwjb+MPaqjsB=w@mail.gmail.com>
 <4ad97604a5b1ada9dd598eb1134779c93c11ad25.camel@joachim-breitner.de>
Message-ID: <7f6da11e-b233-4c74-9f9a-bb8db8ab87df@www.fastmail.com>

That's an interesting point. The docs don't say NullaryTypeClasses is implied by MultiParamTypeClasses, they say it has been supplanted.

> Nullary (no parameter) type classes are enabled with MultiParamTypeClasses; historically, they were enabled with the (now deprecated) NullaryTypeClasses.

As a result I thought it would be odd to vote for both extensions, and voted yes on MultiParamTypeClasses and no on NullaryTypeClasses.

On Mon, Dec 7, 2020, at 15:36, Joachim Breitner wrote:
> 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From rae at richarde.dev  Tue Dec  8 03:47:37 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 8 Dec 2020 03:47:37 +0000
Subject: [ghc-steering-committee] A few more pleas
Message-ID: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>

A plea for DerivingStrategies: GHC currently chooses which strategy to use rather arbitrarily. (For example, did you know that Eq and Ord are derived by GeneralizedNewtypeDeriving whenever possible, even when that extension isn't enabled?) And Show is always derived by the `stock` strategy, even when GND is enabled (and otherwise possible). Instead, DerivingStrategies allows users to be explicit, and (in my opinion) should be a matter of good style, just like top-level type signatures. Having to enable the extension to use good style is an annoying hurdle. While the set of strategies may evolve, the idea of writing out strategies (and their syntax) feels stable to me.

A plea for NamedWildCards: This feature allows type variables beginning with an underscore to be treated as a component in a partial type signature. Critically (for this plea), a type signature with a named wild card will not be accepted without -XPartialTypeSignatures. I do *not* advocate for -XPartialTypeSignatures! So, having -XNamedWildCards on simply means that we get an informative error message when the user writes a type variable beginning with an underscore. The only downside is that programs such as id :: _a -> _a are no longer accepted. But does anyone write type variables with leading underscores? If we think this is at all common, then I would change my mind here. Why have it on by default? Because it's not easily discoverable, and the error messages really are quite nice.

A plea against MonoLocalBinds (and, hence, TypeFamilies): MonoLocalBinds is fork-like: it will mean that some Haskell98 programs will not be accepted. And to get those programs accepted, a user might need ScopedTypeVariables -- in specific, the aspect of ScopedTypeVariables that seems likeliest to change in the future. So I don't think we should have MonoLocalBinds on by default.

Thanks for reading!
Richard

From arnaud.spiwack at tweag.io  Tue Dec  8 08:15:09 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 8 Dec 2020 09:15:09 +0100
Subject: [ghc-steering-committee] #380 GHC2021: A plea for GADTs
In-Reply-To: <CAGK9nuopeKDnWoOPzJufTouQ+uf-ZM9poMs2Dmoua_pVP9vbcQ@mail.gmail.com>
References: <CAH6fHQm5E=Y1ka-7-igb0F0k1eZt3E+EvbwoTodUDAZ-Q1DYng@mail.gmail.com>
 <CAGK9nuopeKDnWoOPzJufTouQ+uf-ZM9poMs2Dmoua_pVP9vbcQ@mail.gmail.com>
Message-ID: <CAH6fHQkfxRrUvkqCJYxv=D3HBVCeMdJfmo+pe=5T9wjMWLGH-Q@mail.gmail.com>

On Fri, Dec 4, 2020 at 5:03 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I don't want GADTs to on by default, because pattern matching on them does
> not work the same as with normal data types (i.e., you often need to have
> an explicitly type signature, or be aware of GHC type checking algorithm to
> know when a type signature is not needed).  So I'd like to be able to see
> explicitly that GADTs might be in play.
>

For what it's worth, you can pattern-match on GADTs with GADTs off (but
then you need TypeFamilies on, which still seems to be on its way to
GHC2021 (though see Richard's “a few more pleas”)).

> :set -XGADTs
> data T a where { MkT :: T Int }
> :set -XNoGADTs
> :set -XTypeFamilies
> f :: T a -> a; f MkT = 0

I really see very little reason to not add GADTs (except MonoLocalBind,
maybe, see Richard's email again, but it applies to TypeFamilies too).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/e1db0de8/attachment.html>

From mail at joachim-breitner.de  Tue Dec  8 09:32:33 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 08 Dec 2020 10:32:33 +0100
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
Message-ID: <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 08.12.2020, 03:47 +0000 schrieb Richard Eisenberg:
> A plea for DerivingStrategies:

concur!

> A plea for NamedWildCards:

concur!

> A plea against MonoLocalBinds (and, hence, TypeFamilies):
> MonoLocalBinds is fork-like: it will mean that some Haskell98
> programs will not be accepted. And to get those programs accepted, a
> user might need ScopedTypeVariables -- in specific, the aspect of
> ScopedTypeVariables that seems likeliest to change in the future. So
> I don't think we should have MonoLocalBinds on by default.

Looking at the stats, this has 279% contentiousness (2.7× as many “no”
votes than “yes” votes in the popular vote). 

I am happy to follow your advice here (and, as always, a plea _against_
an extension is on its own almost enough to kill the extension, as it
is by definition no longer uncontentious).

Would you argue that it should not be included even _if_ we’d include
GADTs and/or TypeFamilies? Or are you saying that MonoLocalBinds
shouldn’t be in; GADTS/TypeFamilies are bad without MonoLocalBinds, and
thus GADTs/TypeFamilies ought to be left out?

cheers,
Joachim

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



From simonpj at microsoft.com  Tue Dec  8 11:56:46 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2020 11:56:46 +0000
Subject: [ghc-steering-committee] Simplify type synonym and type instance
	declarations
Message-ID: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Dear steering committee
Following discussion on !4419 and !4536, I'd like to offer this proposal for discussion
Simplify type synonym and type instance declarations<https://github.com/ghc-proposals/ghc-proposals/pull/386>
I don't know how to get a stable "Rendered" link, but maybe someone can help me.
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/792401e1/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Dec  8 12:01:46 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 8 Dec 2020 13:01:46 +0100
Subject: [ghc-steering-committee] Simplify type synonym and type
	instance declarations
In-Reply-To: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQ=7XP=wXJGw9PXG6qT9meVzoZ69udNHiLMupb=sXZ50Pg@mail.gmail.com>

I edited your PR to add a “rendered” link.

On Tue, Dec 8, 2020 at 12:57 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Dear steering committee
>
> Following discussion on !4419 and !4536, I’d like to offer this proposal
> for discussion
>
> Simplify type synonym and type instance declarations
> <https://github.com/ghc-proposals/ghc-proposals/pull/386>
>
> I don’t know how to get a stable “Rendered” link, but maybe someone can
> help me.
>
> Thanks
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/1e3cef88/attachment.html>

From simonpj at microsoft.com  Tue Dec  8 14:46:50 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2020 14:46:50 +0000
Subject: [ghc-steering-committee] Simplify type synonym and type
 instance declarations
In-Reply-To: <CAH6fHQ=7XP=wXJGw9PXG6qT9meVzoZ69udNHiLMupb=sXZ50Pg@mail.gmail.com>
References: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=7XP=wXJGw9PXG6qT9meVzoZ69udNHiLMupb=sXZ50Pg@mail.gmail.com>
Message-ID: <VI1PR83MB02228375B7F761C3E748CB15ADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Thanks. For future reference, how does one get that link?

S

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 08 December 2020 12:02
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Simplify type synonym and type instance declarations

I edited your PR to add a “rendered” link.

On Tue, Dec 8, 2020 at 12:57 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
Dear steering committee
Following discussion on !4419 and !4536, I’d like to offer this proposal for discussion
Simplify type synonym and type instance declarations<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F386&data=04%7C01%7Csimonpj%40microsoft.com%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eOiKQ%2FV%2BS4QqJE8l4REkv%2B6vtkLj39gxArnTwKGvHko%3D&reserved=0>
I don’t know how to get a stable “Rendered” link, but maybe someone can help me.
Thanks
Simon
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VRM8eUg6K7Ou%2FCQhOyleDXZVRikNE%2BbkbyIbmcSTE%2Fk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/faa9acb7/attachment.html>

From eric at seidel.io  Tue Dec  8 15:29:52 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 08 Dec 2020 10:29:52 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Simplify_type_synonym_and_type?=
 =?utf-8?q?_instance_declarations?=
In-Reply-To: <VI1PR83MB02228375B7F761C3E748CB15ADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=7XP=wXJGw9PXG6qT9meVzoZ69udNHiLMupb=sXZ50Pg@mail.gmail.com>
 <VI1PR83MB02228375B7F761C3E748CB15ADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <c71a6a68-8f6d-4322-a463-365f9fba8357@www.fastmail.com>

It's a little convoluted, but I think this is the easiest way:

1. Open the PR
2. Just below the PR title, you'll see some text

> simonpj wants to merge N commits into master from <branch>

That <branch> is a link to the branch you're trying to merge, click it.

3. Click the "Go to file" button and navigate to your new proposal, in this case 0000-instance-scoping.rst.
4. The current URL is appropriate for the "rendered" link

Eric


On Tue, Dec 8, 2020, at 09:46, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> Thanks. For future reference, how does one get that link?
> 
>  
> 
> S
> 
>  
> 
> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io> 
> *Sent:* 08 December 2020 12:02
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] Simplify type synonym and type 
> instance declarations
> 
>  
> 
> I edited your PR to add a “rendered” link.
> 
>  
> 
> On Tue, Dec 8, 2020 at 12:57 PM Simon Peyton Jones via 
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> > Dear steering committee
> 
> > Following discussion on !4419 and !4536, I’d like to offer this proposal for discussion
> 
> > Simplify type synonym and type instance declarations <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F386&data=04%7C01%7Csimonpj%40microsoft.com%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eOiKQ%2FV%2BS4QqJE8l4REkv%2B6vtkLj39gxArnTwKGvHko%3D&reserved=0>
> 
> > I don’t know how to get a stable “Rendered” link, but maybe someone can help me.
> 
> > Thanks
> 
> > Simon
> 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at 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%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VRM8eUg6K7Ou%2FCQhOyleDXZVRikNE%2BbkbyIbmcSTE%2Fk%3D&reserved=0>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From eric at seidel.io  Tue Dec  8 15:36:12 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 08 Dec 2020 10:36:12 -0500
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
Message-ID: <8145c1eb-20e2-4773-8e2a-7e8953eb0ea8@www.fastmail.com>

On Mon, Dec 7, 2020, at 22:47, Richard Eisenberg wrote:
> A plea for NamedWildCards: This feature allows type variables beginning 
> with an underscore to be treated as a component in a partial type 
> signature. Critically (for this plea), a type signature with a named 
> wild card will not be accepted without -XPartialTypeSignatures. I do 
> *not* advocate for -XPartialTypeSignatures! So, having -XNamedWildCards 
> on simply means that we get an informative error message when the user 
> writes a type variable beginning with an underscore. The only downside 
> is that programs such as id :: _a -> _a are no longer accepted. But 
> does anyone write type variables with leading underscores? If we think 
> this is at all common, then I would change my mind here. Why have it on 
> by default? Because it's not easily discoverable, and the error 
> messages really are quite nice.

Aha, so what you're saying is that with NamedWildCards but not PartialTypeSignatures, GHC will tell you what `_a` was solved for, but it won't accept the resulting program? I didn't realize that NamedWildCards did anything in the absence of PartialTypeSignatures, but I agree that this is better. I was already voting for NamedWildCards, but now I'm inclined to additionally vote against PartialTypeSignatures.

From arnaud.spiwack at tweag.io  Tue Dec  8 15:46:37 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 8 Dec 2020 16:46:37 +0100
Subject: [ghc-steering-committee] Simplify type synonym and type
	instance declarations
In-Reply-To: <c71a6a68-8f6d-4322-a463-365f9fba8357@www.fastmail.com>
References: <VI1PR83MB022289A8ED4BB466BF90A9DFADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQ=7XP=wXJGw9PXG6qT9meVzoZ69udNHiLMupb=sXZ50Pg@mail.gmail.com>
 <VI1PR83MB02228375B7F761C3E748CB15ADCD1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <c71a6a68-8f6d-4322-a463-365f9fba8357@www.fastmail.com>
Message-ID: <CAH6fHQksPi8yRKNTTei9h2NaCauF8hJ0Mdoa_qt09WdbuRtGLg@mail.gmail.com>

That's what I did :-) . Except that I used the file browser rather than the
file switcher.

(In this particular case, there was a lazier way: Vlad had added a link in
the first reply. I just happened to notice it after I was done)

On Tue, Dec 8, 2020 at 4:30 PM Eric Seidel <eric at seidel.io> wrote:

> It's a little convoluted, but I think this is the easiest way:
>
> 1. Open the PR
> 2. Just below the PR title, you'll see some text
>
> > simonpj wants to merge N commits into master from <branch>
>
> That <branch> is a link to the branch you're trying to merge, click it.
>
> 3. Click the "Go to file" button and navigate to your new proposal, in
> this case 0000-instance-scoping.rst.
> 4. The current URL is appropriate for the "rendered" link
>
> Eric
>
>
> On Tue, Dec 8, 2020, at 09:46, Simon Peyton Jones via
> ghc-steering-committee wrote:
> >
> > Thanks. For future reference, how does one get that link?
> >
> >
> >
> > S
> >
> >
> >
> > *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> > *Sent:* 08 December 2020 12:02
> > *To:* Simon Peyton Jones <simonpj at microsoft.com>
> > *Cc:* ghc-steering-committee at haskell.org
> > *Subject:* Re: [ghc-steering-committee] Simplify type synonym and type
> > instance declarations
> >
> >
> >
> > I edited your PR to add a “rendered” link.
> >
> >
> >
> > On Tue, Dec 8, 2020 at 12:57 PM Simon Peyton Jones via
> > ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >
> > > Dear steering committee
> >
> > > Following discussion on !4419 and !4536, I’d like to offer this
> proposal for discussion
> >
> > > Simplify type synonym and type instance declarations <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F386&data=04%7C01%7Csimonpj%40microsoft.com%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eOiKQ%2FV%2BS4QqJE8l4REkv%2B6vtkLj39gxArnTwKGvHko%3D&reserved=0
> >
> >
> > > I don’t know how to get a stable “Rendered” link, but maybe someone
> can help me.
> >
> > > Thanks
> >
> > > Simon
> >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at 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%7C324ead943d654fca718108d89b711f9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637430257447398923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VRM8eUg6K7Ou%2FCQhOyleDXZVRikNE%2BbkbyIbmcSTE%2Fk%3D&reserved=0
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/669631aa/attachment.html>

From iavor.diatchki at gmail.com  Tue Dec  8 16:46:13 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 8 Dec 2020 08:46:13 -0800
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
Message-ID: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>

Hello,

I would like to advocate that things like `DataKinds`, `TypeFamilies`, and
`GADTs` are not enabled by default in GHC2021.     The reason I ask for
this is that unlike many others, I think these extensions convey useful
information about the mindset you should use when working with a specific
code base, which is quite different from working with ordinary Haskell.

I do think it would be quite reasonable to have an umbrella extensions for
FancyTypes too, which would enable all of those, I just don't think they
should be enabled for every Haskell program.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/0a446503/attachment.html>

From iavor.diatchki at gmail.com  Tue Dec  8 16:59:39 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 8 Dec 2020 08:59:39 -0800
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nur3w3ebo3oAA3eTqxW8zsgAS7vtOUzNfEDJOgEREZsv6g@mail.gmail.com>

Hello,

On Mon, Dec 7, 2020 at 7:47 PM Richard Eisenberg <rae at richarde.dev> wrote:

> A plea for DerivingStrategies: GHC currently chooses which strategy to use
> rather arbitrarily. (For example, did you know that Eq and Ord are derived
> by GeneralizedNewtypeDeriving whenever possible, even when that extension
> isn't enabled?) And Show is always derived by the `stock` strategy, even
> when GND is enabled (and otherwise possible). Instead, DerivingStrategies
> allows users to be explicit, and (in my opinion) should be a matter of good
> style, just like top-level type signatures. Having to enable the extension
> to use good style is an annoying hurdle. While the set of strategies may
> evolve, the idea of writing out strategies (and their syntax) feels stable
> to me.
>

I agree that this is a problem, but instead of turning on more extensions
by default, I think we should simply not turn on the GND by default.   I
really think that design for `deriving` is not quite at the state where it
should be on by default.

A plea for NamedWildCards: This feature allows type variables beginning
> with an underscore to be treated as a component in a partial type
> signature. Critically (for this plea), a type signature with a named wild
> card will not be accepted without -XPartialTypeSignatures. I do *not*
> advocate for -XPartialTypeSignatures! So, having -XNamedWildCards on simply
> means that we get an informative error message when the user writes a type
> variable beginning with an underscore. The only downside is that programs
> such as id :: _a -> _a are no longer accepted. But does anyone write type
> variables with leading underscores? If we think this is at all common, then
> I would change my mind here. Why have it on by default? Because it's not
> easily discoverable, and the error messages really are quite nice.
>

It seems odd to turn on an extension that doesn't do anything, and it is
entirely there to make *another* extension work better?   Wouldn't it be
better to make `PartialTypeSignatures` imply `NamedWildCards`?

A plea against MonoLocalBinds (and, hence, TypeFamilies): MonoLocalBinds is
> fork-like: it will mean that some Haskell98 programs will not be accepted.
> And to get those programs accepted, a user might need ScopedTypeVariables
> -- in specific, the aspect of ScopedTypeVariables that seems likeliest to
> change in the future. So I don't think we should have MonoLocalBinds on by
> default.
>

I think you are right on this, so I'll update my vote (I also don't think
that `TypeFamilies` should be on by default, as I mentioned in my other
e-mail)

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/4f44caf0/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Dec  8 17:02:03 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 8 Dec 2020 09:02:03 -0800
Subject: [ghc-steering-committee] Fwd: Updated GHC 20201
In-Reply-To: <CAGK9nuokGj4jHKcrpBq6E-+yu6CS2X8EGzRRb3UCqO+F7XBUUQ@mail.gmail.com>
References: <CAGK9nuqtafbftv-Y8osLeDbj=bxs-JcZ_ubhhrR8pticjT6Lsg@mail.gmail.com>
 <CAGK9nuokGj4jHKcrpBq6E-+yu6CS2X8EGzRRb3UCqO+F7XBUUQ@mail.gmail.com>
Message-ID: <CAGK9nurUYSkrOaMJc4d06-B6Pey0O+27KzvjyzuqT=b=CDToBA@mail.gmail.com>

Hello,

Another update to my vote, to do with MonoLocalBinds, changing to No
-Iavor


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

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

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


Notation
========

BlockArguments: yes
-- ^ I use this all the time.

MultiWayIf: yes
-- ^ This is nice on occasion, and it does not seem to conflict with
-- anything.  Certainly nicer than the alternative `case () of _ | ... `:

LambdaCase: no
-- ^ CHANGED from maybe.  Simon PJ makes a good point that alternatives are
under consideration, so it should not be on yet.

-- | The various literal notations seem useful when you need them
-- and don't conflict with anything.
BinaryLiterals: yes
HexFloatLiterals: yes
NumericUnderscores: yes
NumDecimals: maybe
-- ^ | Not too sure about this last one, I've never used, but it
-- I could see it being useful on occasion.

OverloadedStrings: maybe
-- ^ | CHANGED from yes.  I use this a lot, and would be OK with it being
on all the time, but if others would rather not have it on, it's not a big
deal to turn on when needed.

OverloadedLists: maybe
-- | ^ I've never used this, but I could see it potentially being useful.

OverloadedLabels: no
-- | ^ This one seems for experimenting with various new features
-- (e.g., record selectors), so it seems reasonable to turn it on only
-- when it is needed.

EmptyCase: maybe
-- ^ Seems like a nicer notation for forcing `Void` values.
-- I agree that it is odd that it is strict.  OTOH, it'd be quite useless
-- if it was lazy, so I could go either way.

-- | I haven't really used any of those, so I could go either way:
PostfixOperators: yes
-- CHANGED from maybe.  Convinced by Simon M.

LexicalNegation: maybe
UnicodeSyntax: yes
-- CHANGED from maybe.  Convinced by Joachim.

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

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

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

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

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

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

Arrows: no
-- ^ It's not used a lot, not terribly useful and overall feels "clunky".

ApplicativeDo: maybe
-- ^ I think the core of this extension is really useful,
-- but I would prefer a simpler syntactic version of it,
-- without the various transformations assuming that some laws hold.

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

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

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

RebindableSyntax: no
-- ^ This is a very special case thing

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


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

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

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

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

RoleAnnotations: no
-- ^ This only makes sense with `GeneralisedNewtypeDeriving` which
-- I don't think should be on by default.

StrictData: no
-- ^ This is very unHaskell :)

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

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


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

ViewPatterns: no
-- ^ CHANGES form yes. Useful on occasion, but seems that there might be
better designs aroudn
-- (e.g. guarded patterns)

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

NoPatternGuards: no
-- ^ Conflicts with Haskell2010

NPlusKPatterns: no
-- ^ Conflicts with Haskell2010


Records
=======

-- | I find these two very useful when working with records,
-- especially large ones, and declaring the extension really adds no
-- information:
NamedFieldPuns: yes
RecordWildCards: yes

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

Deriving
=======

-- | Declaring these as extensions explicitly adds very little information.
DeriveGeneric: yes
DeriveLift: yes
DeriveDataTypeable: yes

EmptyDataDeriving: yes
-- ^ Useful for consistency

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


-- | I think the rest of the deriving extensions are not particularly
orthogonal
at the moment, so I don't think we should have them on by default, at least
not yet, even though I find some of them quite useful.

DeriveFunctor: yes
DeriveFoldable: yes
DeriveTraversable: yes
-- ^ The 3 above CHANGED from no.   I was concerned about
conflicting deriving strategies, but I guess these probably always make
sense.

DerivingStrategies: no
DerivingVia: no
GeneralisedNewtypeDeriving: no
DeriveAnyClass: no


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

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

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

ConstraintKinds: yes
-- ^ CHANGED from maybe. These seem like a very nice fit with the rest of
the kind system,
-- so I think we can enable them.  The reason I wrote `maybe` is due to
-- the confusion between constraints and tuples.

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

-- | I haven't really used these much, so I don't have a strong opinion:
ConstrainedClassMethods: maybe
DefaultSignatures: maybe
InstanceSigs: maybe
ExtendedDefaultRules: no
CHANGED from maybe.  This is mostly for GHCi.

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

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

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

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

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

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

Types
=====

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

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

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

-- | These two go together and seem quite useful, especially when writing
-- local type signatures.
ScopedTypeVariables: maybe
ExplicitForAll: maybe
CHANGED from yes to maybe.  Personally, I wouldn't mind if this was on all
the time, but Richard seems to prefer that it is not, so I could go either
way.

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

ImpredicativeTypes: no
-- ^ These are being currently redesigned, so not ready.

MonoLocalBinds: no
-- ^ CHANGED from maybe. I don't know if this one is on by default or not
already...  Convinced by Richard.

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

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

LinearTypes: no
-- ^ Too new to be standardized

TypeApplications: no
-- ^ This one is quite useful, bit it seems that its design and how many
users
-- understand it don't match, so maybe there is more work to be done.

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


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

ForeignFunctionInterface: yes
CApiFFI: yes
CHANGED from no.  FFI is part of Haskell 2010, and so should be on by
default.  If the FFI is on, then it makes a lot of sense to have CApiFFI on
too.


GHCForeignImportPrim: no
InterruptibleFFI: no
UnliftedFFITypes: no
StaticPointers: no


Low Level
=========

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

UnboxedSums: no
UnboxedTuples: no
MagicHash: no
UnliftedNewtypes: yes
CHANGED from no.  This one just makes sense, and while it is not terribly
useful without the other extensions (as there is no way to actually write
an unboxed type in the first place), it would be one fewer extension to
write if one want to use low level stuff

Macros
======

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


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

TemplateHaskell: no
TemplateHaskellQuotes: no
QuasiQuotes: no


Other
=====

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


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

Obsolete/Deprecated
===================
CUSKs: no
TypeInType: no
MonadFailDesugaring: maybe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/ce5bfdf8/attachment.html>

From rae at richarde.dev  Tue Dec  8 19:53:59 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 8 Dec 2020 19:53:59 +0000
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
Message-ID: <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>



> On Dec 8, 2020, at 4:32 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Would you argue that it should not be included even _if_ we’d include
> GADTs and/or TypeFamilies? Or are you saying that MonoLocalBinds
> shouldn’t be in; GADTS/TypeFamilies are bad without MonoLocalBinds, and
> thus GADTs/TypeFamilies ought to be left out?

No. If we have GADTs and/or TypeFamilies, then we should absolutely have MonoLocalBinds -- GADTs and TypeFamilies are wonky without MonoLocalBinds. I'd prefer not to have any of them on by default.

> On Dec 8, 2020, at 10:36 AM, Eric Seidel <eric at seidel.io> wrote:

> Aha, so what you're saying is that with NamedWildCards but not PartialTypeSignatures, GHC will tell you what `_a` was solved for, but it won't accept the resulting program? I didn't realize that NamedWildCards did anything in the absence of PartialTypeSignatures, but I agree that this is better. I was already voting for NamedWildCards, but now I'm inclined to additionally vote against PartialTypeSignatures.

Exactly, yes. I am strongly against PartialTypeSignatures as an extension, as users should have to opt into accepting partially-written programs.

> 
> On Dec 8, 2020, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> It seems odd to turn on an extension [NamedWildCards] that doesn't do anything, and it is entirely there to make *another* extension work better?   Wouldn't it be better to make `PartialTypeSignatures` imply `NamedWildCards`?

NamedWildCards *does* do something on its own -- it just doesn't accept new programs.

If we consider

> foo :: _a -> _a
> foo True = False
> foo False = True

Without NamedWildCards, we get

> Bug.hs:4:5: error:
>     • Couldn't match expected type ‘_a’ with actual type ‘Bool’
>       ‘_a’ is a rigid type variable bound by
>         the type signature for:
>           foo :: forall _a. _a -> _a
>         at Bug.hs:3:1-15
>     • In the pattern: True
>       In an equation for ‘foo’: foo True = False
>     • Relevant bindings include foo :: _a -> _a (bound at Bug.hs:4:1)

With NamedWildCards, we get

> Bug.hs:5:8: error:
>     • Found type wildcard ‘_a’ standing for ‘Bool’
>       To use the inferred type, enable PartialTypeSignatures
>     • In the type signature: foo :: _a -> _a

I think that prefixing a variable name with an underscore is a convenient, lightweight way of asking GHC to tell me what a type should be.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201208/e379091c/attachment-0001.html>

From rae at richarde.dev  Tue Dec  8 19:57:22 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 8 Dec 2020 19:57:22 +0000
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
Message-ID: <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>

I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.

Richard

> On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I would like to advocate that things like `DataKinds`, `TypeFamilies`, and `GADTs` are not enabled by default in GHC2021.     The reason I ask for this is that unlike many others, I think these extensions convey useful information about the mindset you should use when working with a specific code base, which is quite different from working with ordinary Haskell.
> 
> I do think it would be quite reasonable to have an umbrella extensions for FancyTypes too, which would enable all of those, I just don't think they should be enabled for every Haskell program.
> 
> -Iavor
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Wed Dec  9 00:47:17 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 08 Dec 2020 19:47:17 -0500
Subject: [ghc-steering-committee] Fwd: Updated GHC 20201
In-Reply-To: <CAGK9nurUYSkrOaMJc4d06-B6Pey0O+27KzvjyzuqT=b=CDToBA@mail.gmail.com>
References: <CAGK9nuqtafbftv-Y8osLeDbj=bxs-JcZ_ubhhrR8pticjT6Lsg@mail.gmail.com>
 <CAGK9nuokGj4jHKcrpBq6E-+yu6CS2X8EGzRRb3UCqO+F7XBUUQ@mail.gmail.com>
 <CAGK9nurUYSkrOaMJc4d06-B6Pey0O+27KzvjyzuqT=b=CDToBA@mail.gmail.com>
Message-ID: <de2073a7-5e37-4923-bc3b-e10867e6ea62@www.fastmail.com>

Another update to my votes, changing PartialTypeSignatures to "no" based on Richard's explanation that NamedWildCards is independently useful.

## 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
StarIsType: 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
  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
  This is useful for debugging and does not actually accept partial type signatures without PartialTypeSignatures.

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
PartialTypeSignatures: 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
GeneralisedNewtypeDeriving: yes
StandaloneDeriving: yes

DerivingStrategies: maybe

DeriveAnyClass: no
DerivingVia: 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 Tue, Dec 8, 2020, at 12:02, Iavor Diatchki wrote:
> Hello,
> 
> Another update to my vote, to do with MonoLocalBinds, changing to No
> -Iavor
> 
> 
> Module System
> =============
> 
> ImportQualifiedPost: yes
> -- ^ This is relatively new, but it seems quite simple, and it does make
> -- things read nicer.
> 
> -- | These are only needed under very special circumstances,
> -- so it's good to be explicit:
> PackageImports: no
> NoImplicitPrelude: no
> 
> 
> Notation
> ========
> 
> BlockArguments: yes
> -- ^ I use this all the time.
> 
> MultiWayIf: yes
> -- ^ This is nice on occasion, and it does not seem to conflict with
> -- anything.  Certainly nicer than the alternative `case () of _ | ... `:
> 
> LambdaCase: no
> -- ^ CHANGED from maybe.  Simon PJ makes a good point that alternatives 
> are under consideration, so it should not be on yet.
> 
> -- | The various literal notations seem useful when you need them
> -- and don't conflict with anything.
> BinaryLiterals: yes
> HexFloatLiterals: yes
> NumericUnderscores: yes
> NumDecimals: maybe
> -- ^ | Not too sure about this last one, I've never used, but it
> -- I could see it being useful on occasion.
> 
> OverloadedStrings: maybe
> -- ^ | CHANGED from yes.  I use this a lot, and would be OK with it 
> being on all the time, but if others would rather not have it on, it's 
> not a big deal to turn on when needed.
> 
> OverloadedLists: maybe
> -- | ^ I've never used this, but I could see it potentially being useful.
> 
> OverloadedLabels: no
> -- | ^ This one seems for experimenting with various new features
> -- (e.g., record selectors), so it seems reasonable to turn it on only
> -- when it is needed.
> 
> EmptyCase: maybe
> -- ^ Seems like a nicer notation for forcing `Void` values.
> -- I agree that it is odd that it is strict.  OTOH, it'd be quite useless
> -- if it was lazy, so I could go either way.
> 
> -- | I haven't really used any of those, so I could go either way:
> PostfixOperators: yes
> -- CHANGED from maybe.  Convinced by Simon M.
> 
> LexicalNegation: maybe
> UnicodeSyntax: yes
> -- CHANGED from maybe.  Convinced by Joachim.
> 
> NegativeLiterals: no
> -- ^ It seems that `LexicalNegation` might be a nicer way to do this?
> 
> TupleSections: maybe
> -- ^ I don't use this often, but I'd use it more often if it was on by default.
> 
> ImplicitParams: no
> -- ^ I find these quite useful on occasion, but it does seem reasonable
> -- to be explicit when you need them.
> 
> ParallelListComp: yes
> -- ^ I find these to be a very nice generalization to list comprehensions
> -- that makes some code way more readable than using `zip/zipWith`, just
> -- like comprehensions are often nicer than `map` or `concatMap`
> 
> RecursiveDo: yes
> -- ^ Seems useful when you need it, and it doesn't clash with anything,
> -- so I see no reason to not have it on all the time.
> 
> TransformListComp: no
> -- ^ In my mind these are just a bit too much syntactic sugar.
> 
> Arrows: no
> -- ^ It's not used a lot, not terribly useful and overall feels "clunky".
> 
> ApplicativeDo: maybe
> -- ^ I think the core of this extension is really useful,
> -- but I would prefer a simpler syntactic version of it,
> -- without the various transformations assuming that some laws hold.
> 
> QualifiedDo: no
> -- ^ This is neat, but it is too new to be on by default.
> 
> MonadComprehensions: maybe
> -- ^ I never really use these.
> -- On occasion I've wanted `ApplicativeComprehensions` though.
> 
> NondecreasingIndentation: no
> -- ^ This always felt like a hack to me.
> 
> RebindableSyntax: no
> -- ^ This is a very special case thing
> 
> ExplicitNamespaces: maybe
> -- ^ We need this if we also want pattern synonyms.
> 
> 
> Data Types
> ==========
> 
> DatatypeContexts: no
> -- ^ These are not really used much, and usually don't do what people expect.
> 
> ExistentialQuantification: yes
> -- ^ This is quite useful, and has been around for a long time.
> 
> EmptyDataDecls: yes
> -- ^ Seems more consistent to allow this
> 
> RoleAnnotations: no
> -- ^ This only makes sense with `GeneralisedNewtypeDeriving` which
> -- I don't think should be on by default.
> 
> StrictData: no
> -- ^ This is very unHaskell :)
> 
> GADTSyntax: maybe
> -- ^ I personally don't use this, but I know some folks like to write
> -- their `data` declarations in this notation.
> 
> GADTs: no
> -- ^ These can be useful, but it seems reasonable to enable them when
> -- you need them, as they bring in quite a lot of machinery with them.
> 
> 
> Patterns and Guards
> ===================
> BangPatterns: yes
> -- ^ Seem to be useful, and quite popular.
> 
> ViewPatterns: no
> -- ^ CHANGES form yes. Useful on occasion, but seems that there might 
> be better designs aroudn
> -- (e.g. guarded patterns)
> 
> PatternSynonyms: maybe
> -- ^ These are quite useful, but I am not sure how stable is their design.
> 
> NoPatternGuards: no
> -- ^ Conflicts with Haskell2010
> 
> NPlusKPatterns: no
> -- ^ Conflicts with Haskell2010
> 
> 
> Records
> =======
> 
> -- | I find these two very useful when working with records,
> -- especially large ones, and declaring the extension really adds no
> -- information:
> NamedFieldPuns: yes
> RecordWildCards: yes
> 
> -- | These seem to be largely about experimenting with new record
> system, and I don't think any of them are quite ready to be on by default:
> DisambiguateRecordFields: no
> DuplicateRecordFields: no
> NoTraditionalRecordSyntax: no
> 
> Deriving
> =======
> 
> -- | Declaring these as extensions explicitly adds very little information.
> DeriveGeneric: yes
> DeriveLift: yes
> DeriveDataTypeable: yes
> 
> EmptyDataDeriving: yes
> -- ^ Useful for consistency
> 
> StandaloneDeriving: yes
> -- ^ I find this quite useful on occasion, and does not conflict with anything
> 
> 
> -- | I think the rest of the deriving extensions are not particularly orthogonal
> at the moment, so I don't think we should have them on by default, at least
> not yet, even though I find some of them quite useful.
> 
> DeriveFunctor: yes
> DeriveFoldable: yes
> DeriveTraversable: yes
> -- ^ The 3 above CHANGED from no.   I was concerned about conflicting 
> deriving strategies, but I guess these probably always make sense.
> 
> DerivingStrategies: no
> DerivingVia: no
> GeneralisedNewtypeDeriving: no
> DeriveAnyClass: no
> 
> 
> Class System
> ============
> 
> MultiParamTypeClasses: yes
> -- ^ Seems like a natural extension and does not really conflict with anything
> 
> NullaryTypeClasses: yes
> -- ^ Seems like a natural extension and does not really conflict with anything
> 
> ConstraintKinds: yes
> -- ^ CHANGED from maybe. These seem like a very nice fit with the rest 
> of the kind system,
> -- so I think we can enable them.  The reason I wrote `maybe` is due to
> -- the confusion between constraints and tuples.
> 
> -- | These 3 seem to be quite common.  There are some reasons to be careful
> -- when writing `FlexibleInstances`, but it seems that having the extension
> -- does not really help much with those.
> TypeSynonymInstances: yes
> FlexibleInstances: yes
> FlexibleContexts: yes
> 
> -- | I haven't really used these much, so I don't have a strong opinion:
> ConstrainedClassMethods: maybe
> DefaultSignatures: maybe
> InstanceSigs: maybe
> ExtendedDefaultRules: no
> CHANGED from maybe.  This is mostly for GHCi.
> 
> FunctionalDependencies: no
> -- ^ While I quite like the general idea here, I don't think we should
> -- have these on by default.
> 
> QuantifiedConstraints: no
> -- ^ These seem neat, but are quite new to be on by default.
> 
> UndecidableInstances: no
> -- ^ These are a very special case, and ideally should be specified
> -- on a per instance basis.
> 
> IncoherentInstances: no
> -- ^ Why do we even have this? :)
> 
> UndecidableSuperClasses: no
> -- ^ These are a very special case.
> 
> OverlappingInstances: no
> -- ^ This has been subsumed by per-instance pragmas
> 
> Types
> =====
> 
> RankNTypes: yes
> -- ^ These are useful and have been around for a long time.  The design
> -- seems to work well.
> 
> -- | These two seem useful, but I am not sure if they should be on by default.
> -- If so, though, it makes sense to have both of them on.
> StandaloneKindSignatures: maybe
> KindSignatures: maybe
> 
> LiberalTypeSynonyms: maybe
> -- ^ These seem useful, but can lead to some rather confusing situations
> -- where types that look "normal" don't behave as you'd expect
> -- (e..g, writing `[T]` fails because `T` happens to have `forall` in it)
> 
> -- | These two go together and seem quite useful, especially when 
> writing
> -- local type signatures.
> ScopedTypeVariables: maybe
> ExplicitForAll: maybe
> CHANGED from yes to maybe.  Personally, I wouldn't mind if this was on 
> all the time, but Richard seems to prefer that it is not, so I could go 
> either way.
> 
> AllowAmbiguousTypes: no
> -- ^ Often these are unintentional, and are due to a mistake in the program.
> 
> ImpredicativeTypes: no
> -- ^ These are being currently redesigned, so not ready.
> 
> MonoLocalBinds: no
> -- ^ CHANGED from maybe. I don't know if this one is on by default or 
> not already...  Convinced by Richard.
> 
> NoMonomorphismRestriction: yes
> -- ^ The monomrphism restriction seems to cause a lot of confusion, and I
> -- am not sure that it's helped that much with efficiency
> 
> -- | Doesn't really seem to be commonly used.
> PartialTypeSignatures: no
> NamedWildCards: no
> 
> LinearTypes: no
> -- ^ Too new to be standardized
> 
> TypeApplications: no
> -- ^ This one is quite useful, bit it seems that its design and how many users
> -- understand it don't match, so maybe there is more work to be done.
> 
> -- | These are all related to type-level programming, and while I don't think
> -- they should be on by default, it might be useful to have a single flag that
> -- turns a bunch of them on.
> PolyKinds: no
> TypeOperators: no
> StarIsType: maybe
> TypeFamilies: no
> TypeFamilyDependencies: no
> DataKinds: no
> 
> 
> FFI
> ===
> I don't think the FFI should be on by default, as it is used relatively
> infrequently, although it might be nice if `ForeignFunctionInterface`
> implied `CApiFFI`
> 
> ForeignFunctionInterface: yes
> CApiFFI: yes
> CHANGED from no.  FFI is part of Haskell 2010, and so should be on by 
> default.  If the FFI is on, then it makes a lot of sense to have 
> CApiFFI on too.
> 
> 
> GHCForeignImportPrim: no
> InterruptibleFFI: no
> UnliftedFFITypes: no
> StaticPointers: no
> 
> 
> Low Level
> =========
> 
> These are for low-level hacking, so I don't think they should be
> on by default.  However, I wouldn't mind having a flag that enabled
> all of them with a single extension (e.g., `UnliftedTypes`)
> 
> UnboxedSums: no
> UnboxedTuples: no
> MagicHash: no
> UnliftedNewtypes: yes
> CHANGED from no.  This one just makes sense, and while it is not 
> terribly useful without the other extensions (as there is no way to 
> actually write an unboxed type in the first place), it would be one 
> fewer extension to write if one want to use low level stuff
> 
> Macros
> ======
> 
> CPP: no
> This is quite specialized, so it seems reasonable to be explicit about it.
> 
> 
> I don't think these should be on by default, but I wouldn't mind it
> if `TemplateHaskell` implied `QuasiQuotes`, so that when I use TH
> I just need to turn on a single extension.:
> 
> TemplateHaskell: no
> TemplateHaskellQuotes: no
> QuasiQuotes: no
> 
> 
> Other
> =====
> 
> -- | These are part of Safe Haskell and are there to be written explicitly
> Unsafe: no
> Safe: no
> Trustworthy: no
> 
> 
> Strict: no
> -- ^ This is not Haskell! :-)
> 
> Obsolete/Deprecated
> ===================
> CUSKs: no
> TypeInType: no
> MonadFailDesugaring: maybe
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From marlowsd at gmail.com  Wed Dec  9 09:11:24 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 9 Dec 2020 09:11:24 +0000
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
 <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>

I would like to push back here: this seems to be suggesting a fork-like
situation, where we have two kinds of Haskell (fancy and non-fancy). I do
feel quite strongly that we should be converging on a single language
rather than creating splits. Or perhaps the suggestion is that we don't
want these extensions on by default *yet*?

Responding to Iavor's point:

> I think these extensions convey useful information about the mindset you
should use when working with a specific code base, which is quite different
from working with ordinary Haskell.

I personally have been working with these extensions enabled for all my
code for a long time now. I'm by no means a heavy user of "fancy types", I
make occasional use of type families and GADTs to solve specific problems
when they arise. But I'm not even sure what this "different mindset" is - I
certainly don't feel like I have to think differently. Of course it's
entirely possible that I'm just an unsophisticated user and if I understood
how to think about the type system with these extensions my life would be
better!

The one exception that does trip me up is MonoLocalBinds, I often have to
supply a type signature when intuitively I didn't think I needed one.

Cheers
Simon

On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg <rae at richarde.dev> wrote:

> I agree with this. Fancy types are, well, fancy, and users should have to
> boldly declare that they're trying to be fancy.
>
> Richard
>
> > On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> >
> > Hello,
> >
> > I would like to advocate that things like `DataKinds`, `TypeFamilies`,
> and `GADTs` are not enabled by default in GHC2021.     The reason I ask for
> this is that unlike many others, I think these extensions convey useful
> information about the mindset you should use when working with a specific
> code base, which is quite different from working with ordinary Haskell.
> >
> > I do think it would be quite reasonable to have an umbrella extensions
> for FancyTypes too, which would enable all of those, I just don't think
> they should be enabled for every Haskell program.
> >
> > -Iavor
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/f35c7ee4/attachment-0001.html>

From simonpj at microsoft.com  Wed Dec  9 10:20:50 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Dec 2020 10:20:50 +0000
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
 <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
 <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
Message-ID: <VI1PR83MB0222BA9B1F231002D12DEAD7ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

The one exception that does trip me up is MonoLocalBinds, I often have to supply a type signature when intuitively I didn't think I needed one.
I’d like to train Haskell users to get used to MonoLocalBinds.  I simply don’t know a way to give reliable, predictable type generalisation (to get polymorphic types) for local bindings, in the presence of GADTs etc.  I don’t think that situation is going to improve (i.e. it’s not a short term problem) … indeed it may become more pressing as the type system advances.  It’s switched on by TypeFamilies, and I think GADTs, so many of us are using it anyway.

Most local bindings are not polymorphic, so no problem; those that are probably deserve a type signature anyway.   But I accept that there is a cost here: we’re giving up on generalisation for local bindings.

So if we are thinking about the long term future of the language, I think MonoLocalBinds will be a part of it.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 09 December 2020 09:11
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] A plea against "fancy types" in GHC2021

I would like to push back here: this seems to be suggesting a fork-like situation, where we have two kinds of Haskell (fancy and non-fancy). I do feel quite strongly that we should be converging on a single language rather than creating splits. Or perhaps the suggestion is that we don't want these extensions on by default *yet*?

Responding to Iavor's point:

> I think these extensions convey useful information about the mindset you should use when working with a specific code base, which is quite different from working with ordinary Haskell.

I personally have been working with these extensions enabled for all my code for a long time now. I'm by no means a heavy user of "fancy types", I make occasional use of type families and GADTs to solve specific problems when they arise. But I'm not even sure what this "different mindset" is - I certainly don't feel like I have to think differently. Of course it's entirely possible that I'm just an unsophisticated user and if I understood how to think about the type system with these extensions my life would be better!

The one exception that does trip me up is MonoLocalBinds, I often have to supply a type signature when intuitively I didn't think I needed one.

Cheers
Simon

On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.

Richard

> On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:
>
> Hello,
>
> I would like to advocate that things like `DataKinds`, `TypeFamilies`, and `GADTs` are not enabled by default in GHC2021.     The reason I ask for this is that unlike many others, I think these extensions convey useful information about the mindset you should use when working with a specific code base, which is quite different from working with ordinary Haskell.
>
> I do think it would be quite reasonable to have an umbrella extensions for FancyTypes too, which would enable all of those, I just don't think they should be enabled for every Haskell program.
>
> -Iavor
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/d4170c0b/attachment.html>

From marlowsd at gmail.com  Wed Dec  9 11:00:12 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 9 Dec 2020 11:00:12 +0000
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <VI1PR83MB0222BA9B1F231002D12DEAD7ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
 <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
 <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
 <VI1PR83MB0222BA9B1F231002D12DEAD7ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgP+DOUET-dERd-TUUrq+BMxW-CKMOJntXCG3pwzjnhxZ4g@mail.gmail.com>

On Wed, 9 Dec 2020 at 10:20, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> The one exception that does trip me up is MonoLocalBinds, I often have to
> supply a type signature when intuitively I didn't think I needed one.
>
> I’d like to train Haskell users to get used to MonoLocalBinds.  I simply
> don’t know a way to give reliable, predictable *type generalisation* (to
> get polymorphic types) for local bindings, in the presence of GADTs etc.  I
> don’t think that situation is going to improve (i.e. it’s not a short term
> problem) … indeed it may become more pressing as the type system advances.
> It’s switched on by TypeFamilies, and I think GADTs, so many of us are
> using it anyway.
>
>
>
> Most local bindings are not polymorphic, so no problem; those that are
> probably deserve a type signature anyway.   But I accept that there is a
> cost here: we’re giving up on generalisation for local bindings.
>
>
>
> So if we are thinking about the long term future of the language, I think
> MonoLocalBinds will be a part of it.
>

Sure, if MonoLocalBinds is the price of TypeFamilies+GADTs, I'll pay it.
But I have not succeeded in training myself to get used to it. I could be
too old to be retrained though :)

Cheers
Simon



>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 09 December 2020 09:11
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] A plea against "fancy types" in
> GHC2021
>
>
>
> I would like to push back here: this seems to be suggesting a fork-like
> situation, where we have two kinds of Haskell (fancy and non-fancy). I do
> feel quite strongly that we should be converging on a single language
> rather than creating splits. Or perhaps the suggestion is that we don't
> want these extensions on by default *yet*?
>
>
>
> Responding to Iavor's point:
>
>
>
> > I think these extensions convey useful information about the mindset you
> should use when working with a specific code base, which is quite different
> from working with ordinary Haskell.
>
>
>
> I personally have been working with these extensions enabled for all my
> code for a long time now. I'm by no means a heavy user of "fancy types", I
> make occasional use of type families and GADTs to solve specific problems
> when they arise. But I'm not even sure what this "different mindset" is - I
> certainly don't feel like I have to think differently. Of course it's
> entirely possible that I'm just an unsophisticated user and if I understood
> how to think about the type system with these extensions my life would be
> better!
>
>
>
> The one exception that does trip me up is MonoLocalBinds, I often have to
> supply a type signature when intuitively I didn't think I needed one.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg <rae at richarde.dev> wrote:
>
> I agree with this. Fancy types are, well, fancy, and users should have to
> boldly declare that they're trying to be fancy.
>
> Richard
>
> > On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> >
> > Hello,
> >
> > I would like to advocate that things like `DataKinds`, `TypeFamilies`,
> and `GADTs` are not enabled by default in GHC2021.     The reason I ask for
> this is that unlike many others, I think these extensions convey useful
> information about the mindset you should use when working with a specific
> code base, which is quite different from working with ordinary Haskell.
> >
> > I do think it would be quite reasonable to have an umbrella extensions
> for FancyTypes too, which would enable all of those, I just don't think
> they should be enabled for every Haskell program.
> >
> > -Iavor
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at 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%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/368df114/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Dec  9 11:17:55 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 9 Dec 2020 12:17:55 +0100
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>

On Tue, Dec 8, 2020 at 8:54 PM Richard Eisenberg <rae at richarde.dev> wrote:

> No. If we have GADTs and/or TypeFamilies, then we should absolutely have
> MonoLocalBinds -- GADTs and TypeFamilies are wonky without MonoLocalBinds.
> I'd prefer not to have any of them on by default.
>

Do we agree that this is not tenable in the long term? At some point, GADTs
and TypeFamilies need to be in by default. When is that horizon? For
context, these features have been with us for 12 years (since GHC 6.8.1).
And quite stable in the last 6 years. They are not going anywhere, they are
very widely used.

Just as much, I'd say MonoLocalBinds really wants to be the default
(supporting `NoMonoLocalBinds` at all probably has some non-trivial
implementation costs, I would not be sad to see this go, even if it's a bit
hard to get rid of in the current state because it does mean breaking
compatibility with Haskell98 and Haskell2010, in fact, we still support
`DatatypeContext` at the cost of code).

Maybe GHC2021 shouldn't have these (it's not my opinion, but it's
arguable). Since the value of GHC2021 is “conservatism” (then again, we
seem to be adding in StandaloneKindSignatures and NamedFieldPuns, which do
not sound very conservative to me). But then, they are the first two
extensions that should be considered for GHC2022. Do we agree on this? Or
would you rather see these stay in their standalone extensions forever?
(which I would find, personally, rather alarming)

Exactly, yes. I am strongly against PartialTypeSignatures as an extension,
> as users should have to opt into accepting partially-written programs.
>

How is a partial type signature a partially-written program? Does the
absence of type signature on a binding make a program partially written?
Because a partial type signature is more than no signature at all, so it
should be considered less partial at least.

Plus, partial type signatures give a warning (which, I've argued before, is
probably more than you actually want cf
https://gitlab.haskell.org/ghc/ghc/-/issues/16220).

I don't know that we want PartialTypeSignature this time around. And there
may be reason to never want them. But I'd say “users should have to opt
into accepting partially-written programs” is not one of them.

With NamedWildCards, we get
>
> Bug.hs:5:8: error:
>     • Found type wildcard ‘_a’ standing for ‘Bool’
>       To use the inferred type, enable PartialTypeSignatures
>     • In the type signature: foo :: _a -> _a
>
>
> I think that prefixing a variable name with an underscore is a convenient,
> lightweight way of asking GHC to tell me what a type should be.
>
>
On the other hand, I think that I agree with this, and that I will change
my vote.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/9cf95785/attachment.html>

From arnaud.spiwack at tweag.io  Wed Dec  9 11:31:25 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 9 Dec 2020 12:31:25 +0100
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <VI1PR83MB0222BA9B1F231002D12DEAD7ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
 <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
 <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
 <VI1PR83MB0222BA9B1F231002D12DEAD7ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQkexPxQU3-pBjQiRkTxXF=YX8GDf8crMJA9Wks-biXSMQ@mail.gmail.com>

On Wed, Dec 9, 2020 at 11:21 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> I’d like to train Haskell users to get used to MonoLocalBinds.  I simply
> don’t know a way to give reliable, predictable *type generalisation* (to
> get polymorphic types) for local bindings, in the presence of GADTs etc.  I
> don’t think that situation is going to improve (i.e. it’s not a short term
> problem) … indeed it may become more pressing as the type system advances.
> It’s switched on by TypeFamilies, and I think GADTs, so many of us are
> using it anyway.
>
>
>
> Most local bindings are not polymorphic, so no problem; those that are
> probably deserve a type signature anyway.   But I accept that there is a
> cost here: we’re giving up on generalisation for local bindings.
>
>
>
> So if we are thinking about the long term future of the language, I think
> MonoLocalBinds will be a part of it.
>

(I was arguing in the same direction in the other thread before I saw
Simon's email)

I would like to add that, personally, in the past few years, I've been
completely converted to the MonoLocalBinds religion. Generalising is hard.
Generalising non-pure-ML types and terms is often impossible. The
algorithmic of generalising is really tricky. You need to care about scopes
(don't generalise a variable which is used by someone else!).
Generalisation tends to end up taking over the entire type checking
algorithm. And it shouldn't be surprising that it is hard: we're changing
existential quantifiers into universal quantifiers. It's a weird thing to
do.

Generalising at toplevel is much easier. Though, to be honest, I'm
increasingly of the opinion that MonoLocalBinds doesn't go far enough, and
that we oughtn't generalise at top level either (unless we have a type
signature). And, actually, this is what happens with multiplicities in GHC
9.0: we never infer a multiplicity-polymorphic type. (it's not really a big
restriction since we tend to write signatures at toplevel always, anyway).

As a side remark: I don't think MonoLocalBind ever caused a file of mine to
stop compiling when I turn on TypeFamilies or GADTs (which does happen to
most of my files). So I assume that I don't tend to rely on generalisation
all that much.

PS: I'd like to add that I'm really happy that we are having these
discussions. There seems to be a lot of implicitness in how GHC is
designed, and facing GHC2021 forces us to reveal this implicitness. This
is, in my opinion, immensely productive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/d2b425d2/attachment.html>

From marlowsd at gmail.com  Wed Dec  9 11:37:05 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 9 Dec 2020 11:37:05 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Third status update
In-Reply-To: <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <6ab6a5a84af145a0364d7358eaf8d5beca090438.camel@joachim-breitner.de>
Message-ID: <CANsrgP+MtCcmGNhFGt4Om747V+qOPGzbWsVMAMcHz1MQisjW3Q@mail.gmail.com>

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 <mail at joachim-breitner.de>
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-ghc2021.rst#data
> 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/4b433f92/attachment-0001.html>

From simonpj at microsoft.com  Wed Dec  9 12:08:01 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Dec 2020 12:08:01 +0000
Subject: [ghc-steering-committee] GHC2021: a final plea
	for	ScopedTypeVariables
In-Reply-To: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>
References: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>
Message-ID: <VI1PR83MB0222E0F046E7A0CD7DB5E8F1ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Most of the criticisms are around the fact the the current manifestation is not ideal, something I agree with. I would say in this case we should not let perfect be the enemy of good: if during the years, once types in patterns or Dependent Haskell extensions require this, the scoping mechanism needs to change, we can do it. But as of now, ScopedTypeVariables is a very important piece in the flavour of Haskell in main usage (given its mainstream acceptance).

I agree with this.  Not having scoped type variables (in any form) is a huge blemish.  The existing design may not be perfect, but it’s worked rather well for a long time.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 07 December 2020 20:26
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] GHC2021: a final plea for ScopedTypeVariables

Dear all,
I’ll try once again (this is the last one, I’ll promise) to convince the Committee of including ScopedTypeVariables as part of GHC2021. It has been with us for a long time — so their problems seem well understood — and the community seems to want it as part of this new “language version” — which means that people are really using it.

Most of the criticisms are around the fact the the current manifestation is not ideal, something I agree with. I would say in this case we should not let perfect be the enemy of good: if during the years, once types in patterns or Dependent Haskell extensions require this, the scoping mechanism needs to change, we can do it. But as of now, ScopedTypeVariables is a very important piece in the flavour of Haskell in main usage (given its mainstream acceptance).

forall (member :: Committee). Regards -> member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/72622fb3/attachment.html>

From mail at joachim-breitner.de  Wed Dec  9 13:40:13 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Dec 2020 14:40:13 +0100
Subject: [ghc-steering-committee] GHC2021: a final plea
	for	ScopedTypeVariables
In-Reply-To: <VI1PR83MB0222E0F046E7A0CD7DB5E8F1ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>
 <VI1PR83MB0222E0F046E7A0CD7DB5E8F1ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <7efd1e879b3cc5966295ea58833418e2e835d002.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> I agree with this.  Not having scoped type variables (in any form) is
> a huge blemish.  The existing design may not be perfect, but it’s
> worked rather well for a long time.

The same is true for ViewPatterns, which are even more harmless (clear
syntactic opt-in; no spooky effect at a distance when type signature
and definition are far apart).

There we argued that the fact that we don’t think it’s perfect, and
some wiki page with an alternative design exists, was enough to plea
against it.

Here, the situation seems equivalent (we know of better designs, namely
binding type variables on the LHS of the equation).

Can we justify why we go one way here and another way there? Is it
because ViewPatterns are just mere convenience, and ScopedTypeVariables
are absolutely needed for some things?

Cheers,
Joachim



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



From mail at joachim-breitner.de  Wed Dec  9 13:40:15 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Dec 2020 14:40:15 +0100
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
Message-ID: <383963ce28676e4e9c090e652f511f95ee3f2b29.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 09.12.2020, 12:17 +0100 schrieb Spiwack, Arnaud:
> Maybe GHC2021 shouldn't have these (it's not my opinion, but it's
> arguable). Since the value of GHC2021 is “conservatism” (then again,
> we seem to be adding in StandaloneKindSignatures and NamedFieldPuns,
> which do not sound very conservative to me). But then, they are the
> first two extensions that should be considered for GHC2022. Do we
> agree on this? Or would you rather see these stay in their standalone
> extensions forever? (which I would find, personally, rather alarming)

what I deduce from this discussion is that there is quite a lot of
discussion to be had, and I’d prefer to have that next round. Let’s
crawl before we walk, and get a GHC2021 out that nobody will object to.
When it comes to GHC2022, we can focus on the harder ones. Plus there
is one more year to ponder these issues in the back of our head.


What I also got from this discussion was learning why sometimes a
`where foo = 1000` works at different number types, and sometimes not.
It depends on whether I am using GADTs or TypeFamilies somewhere in the
file! Who’d have thought…


cheers,
Joachim

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



From trupill at gmail.com  Wed Dec  9 13:43:44 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 9 Dec 2020 13:43:44 +0000
Subject: [ghc-steering-committee] GHC2021: a final plea for
	ScopedTypeVariables
In-Reply-To: <7efd1e879b3cc5966295ea58833418e2e835d002.camel@joachim-breitner.de>
References: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>
 <VI1PR83MB0222E0F046E7A0CD7DB5E8F1ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <7efd1e879b3cc5966295ea58833418e2e835d002.camel@joachim-breitner.de>
Message-ID: <CAHnFXOv1aDjD0RrAf4mzAN4MJwoV1BNBYuVaAWd2+RVxs=ZeZQ@mail.gmail.com>

On 9 Dec 2020 at 14:40:13, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
>
> I agree with this.  Not having scoped type variables (in any form) is
>
> a huge blemish.  The existing design may not be perfect, but it’s
>
> worked rather well for a long time.
>
>
> The same is true for ViewPatterns, which are even more harmless (clear
> syntactic opt-in; no spooky effect at a distance when type signature
> and definition are far apart).
>
> There we argued that the fact that we don’t think it’s perfect, and
> some wiki page with an alternative design exists, was enough to plea
> against it.
>
> Here, the situation seems equivalent (we know of better designs, namely
> binding type variables on the LHS of the equation).
>
> Can we justify why we go one way here and another way there? Is it
> because ViewPatterns are just mere convenience, and ScopedTypeVariables
> are absolutely needed for some things?
>

This is what I think at least (I also voted ‘yes’ for ViewPatterns, but I
wouldn’t mind not having them). No ViewPatterns, I just need one extra
‘case’ to stay in GHC2021.

Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/de641731/attachment-0001.html>

From simonpj at microsoft.com  Wed Dec  9 13:55:24 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Dec 2020 13:55:24 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
Message-ID: <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I’ve replied on GitHub.  Generally in favour.  But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”.  WE can learn from experience.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 03 December 2020 20:17
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance

Dear Committee,

Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.

I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.

Regards,
Alejandro

On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.

I've requested that the committee consider the updates in parallel with community feedback.

Thanks,
Richard


On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.

Regards,
Alejandro

On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.

On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:

Hi,

Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
> Dear all,
> This proposal suggests adding syntax for a general notion of
> modifiers, like the ones we’ve been talking about lately affecting
> linearity or matchability of arrows. For example, if linear types and
> unsaturated families are accepted as they stand, we would have `Int
> #1 -> @U Bool` (or something like that), whereas with this proposal
> we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>
> Since the amount of modifiers is likely to increase in the future, I
> think it’s a great idea to agree and reserve such syntax, instead of
> coming up with different ways on each proposal. I thus recommend
> acceptance of this proposal.
>
> The proposal itself:
> (1) introduces syntax for modifiers in types and defines how to
> type/kind check them,
> (2) reserved such syntax for other uses in declarations and terms.
>
> I think the proposal still has its merits only with (1), even though
> I lean towards accepting both parts of it.

I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?

Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.

The fact that we special-case %1 supports that.

The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?

I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….

Not great syntax, because not concise, enough, but morally I’d feel
more at ease with

  Int %(multiplicity Many) -> Int
  Int %(multiplicity 1) -> Int
  Int %(multiplicity m) -> Int

where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to

  Int %oneShot -> Int

and

  Int %(matchability M) -> Int

and maybe even

  foo (%type [a]) -- where foo :: forall a -> ()

which is a modifier that


So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.

Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.

  constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
  infixexp ::= lexp {modifier} qop infixexp



Cheers,
Joachim


--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/1beb01ab/attachment-0001.html>

From marlowsd at gmail.com  Wed Dec  9 14:52:46 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 9 Dec 2020 14:52:46 +0000
Subject: [ghc-steering-committee] GHC2021: a final plea for
	ScopedTypeVariables
In-Reply-To: <7efd1e879b3cc5966295ea58833418e2e835d002.camel@joachim-breitner.de>
References: <CAHnFXOvtDSwQP4rSRHg36yD_o8KVitifkE3c3zGJUuF0-5RtuA@mail.gmail.com>
 <VI1PR83MB0222E0F046E7A0CD7DB5E8F1ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <7efd1e879b3cc5966295ea58833418e2e835d002.camel@joachim-breitner.de>
Message-ID: <CANsrgPJZ4MAZbZaWeE3BrzzNMbMAnG-QLQOHV1ROgLJPM7S38Q@mail.gmail.com>

On Wed, 9 Dec 2020 at 13:40, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I agree with this.  Not having scoped type variables (in any form) is
> > a huge blemish.  The existing design may not be perfect, but it’s
> > worked rather well for a long time.
>
> The same is true for ViewPatterns, which are even more harmless (clear
> syntactic opt-in; no spooky effect at a distance when type signature
> and definition are far apart).
>
> There we argued that the fact that we don’t think it’s perfect, and
> some wiki page with an alternative design exists, was enough to plea
> against it.
>
> Here, the situation seems equivalent (we know of better designs, namely
> binding type variables on the LHS of the equation).
>
> Can we justify why we go one way here and another way there? Is it
> because ViewPatterns are just mere convenience, and ScopedTypeVariables
> are absolutely needed for some things?
>

Yes to your last point here. But other points to note about ViewPatterns:

Technically ViewPatterns are not just a convenience, at least when combined
with PatternSynonyms. The only way that you can write a PatternSynonym that
does some arbitrary computation in the pattern is to use ViewPatterns -
*this* is the killer feature of PatternSynonyms, because it provides full
power to abstract over constructor names. You can define a constructor that
expands to some arbitrary computation in the pattern. Here's an example:
https://stackoverflow.com/questions/43838550/using-viewpatterns-and-patternsynonyms-to-simply-pattern-matches

(The alternative ViewPatterns design would also provide this functionality,
incidentally.)

But anyway, this is not an argument to accept ViewPatterns, because it
doesn't look like PatternSynonyms will be in GHC2021 (shame!).

Outside of the PatternSynonyms use-case, I don't think ViewPatterns are all
that widely used. We have figures of 7% proliferation and 20% popularity,
but that doesn't tell us (1) how much the extension is really used, and (2)
how often it is used because it's the only way to do certain things with
PatternSynonyms. Some more data would be nice. I base my intuition here on
the fact that I hardly ever encounter any ViewPatterns, but I could well be
living in a bubble of some kind.

If the extension really isn't very widely-used, and we think the design
might change, we can limit the churn in the future by avoiding having the
extension on by default.

Cheers
Simon




>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/a53ab0fa/attachment.html>

From arnaud.spiwack at tweag.io  Wed Dec  9 14:59:43 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 9 Dec 2020 15:59:43 +0100
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>

It's always possible to change. I don't think accepting a proposal means
(or ought to mean) that we are locked into anything. Accepting a proposal
means that we won't oppose a design-related argument to a PR that
implements (part or all of) an accepted proposal.

I don't know how to quantify the degree of confidence that we have in the
stability of a proposal. Here we are all saying: this is better than
anything so far, and we rather need something like this to be a thing, but
it's really a shot in the dark. And this lack of confidence will be
reflected in the manual description. But even if we are confident in the
stability of a proposal, it may very well happen that it changes
dramatically, even soon.

On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> I’ve replied on GitHub.  Generally in favour.  But mark it as
> experimental… I don’t want to be locked into “we decided on this in Dec
> 2020 so now it’s too late”.  WE can learn from experience.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 03 December 2020 20:17
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
> Recommendation: Acceptance
>
>
>
> Dear Committee,
>
>
>
> Richard has requested for us to consider the new version of this proposal.
> As opposed to the previous version, this one is only about reserving syntax
> for “modifiers”, which at the beginning would be used for things like
> linearity or matchability of arrows.
>
>
>
> I think this is a good proposal, and one which would save us from
> re-considering syntax for every possible extension (and if linearity
> appears before the arrow and matchability after it, where would a future
> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>
> To my surprise, I found myself leaning against. So I updated and
> simplified the proposal to remove Modifier. This makes modifiers a bit more
> magical, but more likely to actually work in practice. The type inference
> story previously may have been intractable.
>
>
>
> I've requested that the committee consider the updates in parallel with
> community feedback.
>
>
>
> Thanks,
>
> Richard
>
>
>
> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>
>
> After some discussion in the GitHub thread, changes are going to arrive to
> the proposal. I think the best is to send the proposal back to the “Needs
> revision” state.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>
> I left a few comments and questions on the PR itself, but I'm leaning
> towards rejecting the proposal in its current form as well. This doesn't
> (yet) feel like a generic mechanism, in particular because the only
> modifier that has been specified would be deeply wired into GHC itself.
>
> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>
> Hi,
>
>
>
> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>
> Mena:
>
> > Dear all,
>
> > This proposal suggests adding syntax for a general notion of
>
> > modifiers, like the ones we’ve been talking about lately affecting
>
> > linearity or matchability of arrows. For example, if linear types and
>
> > unsaturated families are accepted as they stand, we would have `Int
>
> > #1 -> @U Bool` (or something like that), whereas with this proposal
>
> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>
> >
>
> > Since the amount of modifiers is likely to increase in the future, I
>
> > think it’s a great idea to agree and reserve such syntax, instead of
>
> > coming up with different ways on each proposal. I thus recommend
>
> > acceptance of this proposal.
>
> >
>
> > The proposal itself:
>
> > (1) introduces syntax for modifiers in types and defines how to
>
> > type/kind check them,
>
> > (2) reserved such syntax for other uses in declarations and terms.
>
> >
>
> > I think the proposal still has its merits only with (1), even though
>
> > I lean towards accepting both parts of it.
>
>
>
> I like the idea of reserving syntax here, but parts of the proposal
>
> smell a bit like premature generalization to me. Are we confident that
>
> all annotations we eventually would like to use with this feature can
>
> be expressed as types of a kind that is an instance of Modifier? Or
>
> should we reserve the ability to have annotations that don't fit that
>
> model?
>
>
>
> Would we ever have annotation that may affect phases earlier than than
>
> typechecking? What if we want to use (%type e) and (%data e) to help
>
> with the SingleNamepace issues? Look like useful annotations to me, but
>
> I am not sure if they fit the framework proposed here.
>
>
>
> The fact that we special-case %1 supports that.
>
>
>
> The proposal explicitly has to state “No modifier polymorphism!”. But
>
> isn't that indication that using the type system to model the various
>
> modifiers might be the wrong tool?
>
>
>
> I wonder if there is a way where the %(…) on it’s own only reserve
>
> syntax, and the various uses of that syntax can be disambiguated
>
> _statically_ based on the content of ….
>
>
>
> Not great syntax, because not concise, enough, but morally I’d feel
>
> more at ease with
>
>
>
>   Int %(multiplicity Many) -> Int
>
>   Int %(multiplicity 1) -> Int
>
>   Int %(multiplicity m) -> Int
>
>
>
> where multiplicity is a modifier keyword, to express the existing
>
> features (including implicit generalization of m). Then we can extend
>
> this to
>
>
>
>   Int %oneShot -> Int
>
>
>
> and
>
>
>
>   Int %(matchability M) -> Int
>
>
>
> and maybe even
>
>
>
>   foo (%type [a]) -- where foo :: forall a -> ()
>
>
>
> which is a modifier that
>
>
>
>
>
> So at the moment, I am inclined to reject this proposal, until I am
>
> convinced that we are not painting ourselves into a “all modifiers are
>
> types of special kinds and that’s all the syntax and behaviour we ever
>
> need” corner.
>
>
>
> Minor detail: If we can annotate infix use of the (->) “type operator”,
>
> should we also be able to annotate other infix operators, i.e.
>
>
>
>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>
>   infixexp ::= lexp {modifier} qop infixexp
>
>
>
>
>
>
>
> Cheers,
>
> Joachim
>
>
>
>
>
> --
>
> Joachim Breitner
>
>   mail at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
>
>
>
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/c778c3d0/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Dec  9 17:00:16 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 9 Dec 2020 09:00:16 -0800
Subject: [ghc-steering-committee] A plea against "fancy types" in GHC2021
In-Reply-To: <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
References: <CAGK9nurCXKW5DV1Wf5F=WQfeUdEx9ioc02nsmJr4JoEbsidsEw@mail.gmail.com>
 <010f017643ee09ec-7391371b-73f4-457e-bae7-3b619d0c17e9-000000@us-east-2.amazonses.com>
 <CANsrgPLV-_RL2KfjJ_CUQfzEfiu0qBPrq9_h2b+tWhxKan92Zg@mail.gmail.com>
Message-ID: <CAGK9nupKnEx28pW3TEMBEgbFw2HkaP9DEQ6nLQb39Pvhm4PEbw@mail.gmail.com>

Hello,

I don't have a strong feeling about `MonoLocalBinds`, I could take it or
leave it, even though it disables some Haskell'98 programs.

However the "fancy types" situation is different:

   1. I don't see "FancyTypes" as being fork-like, but rather as simply
being an extension in the traditional GHC sense.   This is more modular,
and is in the spirit to the multiple languages of Dr. Racket.  I see GHC's
ability to control what extensions are on as a strength not a weakness---in
my mind GHC 2021 just helps control the extensions at a slightly coarser
granularity.

   2. I am indeed not convinced that these extensions are in their "final"
form, even though they are useful at the moment,   I am thinking of things
like:

   * many people dislike the aspect of GADTs where the declared parameters
don't really bind anything, and writing records in that notation is quite
clunky, it is still rather hard to explain when one needs to write a type
signature when matching on a GADT.

   * for many use cases (the majority in my experience) `DataKinds` does
not work the way I'd want it to, as typically you only want to define types
of a new kind, and there is no need to pollute the value level with unused
constructors---we have an accepted proposal about this, but it was never
implemented, as I'd probably have to implement it, and I don't have the
time to do it.   There is also the unfortunate backtick situation, etc.

   * type families have dark semantic corners (e.g., things like `Any`
which may refer to inhabitants of empty types), and also have numerous
extensions/variants (e.g., dependent parameters, partial applications), so
I'd rather turn them on by default when they stop growing.  Also I imagine
DH has opinions on how one should write "type" functions.

-Iavor


On Wed, Dec 9, 2020 at 1:11 AM Simon Marlow <marlowsd at gmail.com> wrote:

> I would like to push back here: this seems to be suggesting a fork-like
> situation, where we have two kinds of Haskell (fancy and non-fancy). I do
> feel quite strongly that we should be converging on a single language
> rather than creating splits. Or perhaps the suggestion is that we don't
> want these extensions on by default *yet*?
>
> Responding to Iavor's point:
>
> > I think these extensions convey useful information about the mindset you
> should use when working with a specific code base, which is quite different
> from working with ordinary Haskell.
>
> I personally have been working with these extensions enabled for all my
> code for a long time now. I'm by no means a heavy user of "fancy types", I
> make occasional use of type families and GADTs to solve specific problems
> when they arise. But I'm not even sure what this "different mindset" is - I
> certainly don't feel like I have to think differently. Of course it's
> entirely possible that I'm just an unsophisticated user and if I understood
> how to think about the type system with these extensions my life would be
> better!
>
> The one exception that does trip me up is MonoLocalBinds, I often have to
> supply a type signature when intuitively I didn't think I needed one.
>
> Cheers
> Simon
>
> On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> I agree with this. Fancy types are, well, fancy, and users should have to
>> boldly declare that they're trying to be fancy.
>>
>> Richard
>>
>> > On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>> >
>> > Hello,
>> >
>> > I would like to advocate that things like `DataKinds`, `TypeFamilies`,
>> and `GADTs` are not enabled by default in GHC2021.     The reason I ask for
>> this is that unlike many others, I think these extensions convey useful
>> information about the mindset you should use when working with a specific
>> code base, which is quite different from working with ordinary Haskell.
>> >
>> > I do think it would be quite reasonable to have an umbrella extensions
>> for FancyTypes too, which would enable all of those, I just don't think
>> they should be enabled for every Haskell program.
>> >
>> > -Iavor
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/11d8ccdf/attachment.html>

From simonpj at microsoft.com  Wed Dec  9 17:02:56 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Dec 2020 17:02:56 +0000
Subject: [ghc-steering-committee] Please review #313: Delimited
 continuation primops, Shepherd: Simon Marlow
In-Reply-To: <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>
 <CANsrgPLyQ2Se80DQBFFysRu6bt=3yA80VmEwX_CEvNES1Q+vOQ@mail.gmail.com>
Message-ID: <VI1PR83MB02221CB4041B56920A0ECB1DADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

I’m generally strongly supportive of this proposal.

Again, we might see some movement around the edges, but both Daan Leijen and Amr Sabry have given it a thumbs up, so I think it’s fundamentally sound.

There may be a few points to clarify, but fundamentally let’s accept.

Simon


From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 23 November 2020 14:38
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Please review #313: Delimited continuation primops, Shepherd: Simon Marlow

Committee,

We have been asked to review

#313: Delimited continuation primops
https://github.com/ghc-proposals/ghc-proposals/pull/313<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F313&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293529012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Le0GAZdh2JEcQssZE0BT4dI0vyfI%2FomjgqLnpTAUi3o%3D&reserved=0>
https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flexi-lambda%2Fghc-proposals%2Fblob%2Fdelimited-continuation-primops%2Fproposals%2F0000-delimited-continuation-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293539008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ulO4Rdn%2Fn5LHXlOpfhHDds9RxwF6t1pC9jZVOQgQPzA%3D&reserved=0>

Summary

The proposal makes no language changes, it only adds three primops<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flexi-lambda%2Fghc-proposals%2Fblob%2Fdelimited-continuation-primops%2Fproposals%2F0000-delimited-continuation-primops.md%23proposed-change-specification&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293539008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dBgHuMm3STiaB6be9CJ5sLsuJksOUlb6kp9SB9E1R04%3D&reserved=0>.

The main motivation is to support building efficient implementations of Algebraic Effect systems, which depend on being able to efficiently capture a continuation. Currently this is done explicitly, which imposes a severe performance penalty.

These primops are the minimal support needed to be able to capture a continuation and apply it at runtime, together with some basic type safety via the PromtTag type to ensure that at least we don't replace a continuation with a computation of a different type.  (there are other ways to go wrong with these primops though, they're not a safe interface by themselves: they need to be wrapped in a safe library).

The primops are implemented by copying chunks of stack into the heap. This is something that GHC's runtime already does a lot of, so it's not a new concept, although it does require a new closure type and knock-on changes across several files in the runtime (though it's mainly mechanical). There's a prototype implementation here: https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Flexi.lambda%2Fghc%2F-%2Fcompare%2Fmaster...first-class-continuations%3Fview%3Dinline&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293549000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OHMl2XVxh6DJdDLb68I9hqC6IOTJLRzLVujTfKRfnP8%3D&reserved=0>

Decision

I'm going to tentatively recommend acceptance.

  *   This is a sensible choice for the primtives, being the most general of the alternatives, as explained in the proposal.<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flexi-lambda%2Fghc-proposals%2Fblob%2Fdelimited-continuation-primops%2Fproposals%2F0000-delimited-continuation-primops.md%23operational-semantics&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293549000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UZ4m3i95xS%2FwQXZZ5tyC6b3M%2B%2BsNW%2BzQEAaxhHviAcc%3D&reserved=0>
  *   Would the new primops impose a significant ongoing maintenance burden? Having looked at the patch, although there are some missing pieces, I don't think the new concepts impose any significant new requirements on other parts of the runtime.
  *   I suspect there may be some difficulties around unsafePerformIO, so I raised that on the github thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F313%23issuecomment-732181948&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293558999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=T7Bg1Cc5JWnLu5Jei4m2U%2FdGxZLTUoWWW5d0P3rR%2Bic%3D&reserved=0>
Thoughts?



On Sat, 12 Sep 2020 at 22:59, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Delimited continuation primops
has been proposed by Alexis King
https://github.com/ghc-proposals/ghc-proposals/pull/313<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F313&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293558999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pMZVPIAfsh9qyoL6DL86yHyFfiPWn4naTPBy0CLI25A%3D&reserved=0>
https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flexi-lambda%2Fghc-proposals%2Fblob%2Fdelimited-continuation-primops%2Fproposals%2F0000-delimited-continuation-primops.md&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293568989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Zw2T0xtD1ajgsbZmMR9HuWEWKW%2Fem5XXw1%2BGMJhtYDE%3D&reserved=0>

I’ll propose Simon Marlow as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=04%7C01%7Csimonpj%40microsoft.com%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293568989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FGqnupqKk9ivMF5gNqqgXyO58owCNR%2BBVZ1N6JagCUM%3D&reserved=0>

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293578982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j5fdBTeQJbnPWb8tdnA%2FzgDEUoIUJhkwMrg9kfrGFrI%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C84a3108a4ea94f00a6ba08d88fbd6bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417393293578982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=J1gQ1iUMCnmJCkx7uu1qMRtZh7JCU18bz89lklbjmC8%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/c7177d2f/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Dec  9 17:19:08 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 9 Dec 2020 09:19:08 -0800
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <383963ce28676e4e9c090e652f511f95ee3f2b29.camel@joachim-breitner.de>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
 <383963ce28676e4e9c090e652f511f95ee3f2b29.camel@joachim-breitner.de>
Message-ID: <CAGK9nurvcUuysQO=uz7sJ9mM2T27dXeXaPct2O3-t8jCDzQDNQ@mail.gmail.com>

On Wed, Dec 9, 2020 at 5:40 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

>
> What I also got from this discussion was learning why sometimes a
> `where foo = 1000` works at different number types, and sometimes not.
> It depends on whether I am using GADTs or TypeFamilies somewhere in the
> file! Who’d have thought…
>
>
Actually `where foo = 1000` wouldn't be affected by `MonoLocalBinds` (but
would be by the `MonomorphsimRestriction`, fun right :-)  ).
`MonoLocalBinds` only affects local bindings that depend on something from
a pattern (i.e., declaration that you can't
just move to the top level because they depend on something locally bound)

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/750866d6/attachment.html>

From mail at joachim-breitner.de  Wed Dec  9 17:27:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Dec 2020 18:27:59 +0100
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <CAGK9nurvcUuysQO=uz7sJ9mM2T27dXeXaPct2O3-t8jCDzQDNQ@mail.gmail.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
 <383963ce28676e4e9c090e652f511f95ee3f2b29.camel@joachim-breitner.de>
 <CAGK9nurvcUuysQO=uz7sJ9mM2T27dXeXaPct2O3-t8jCDzQDNQ@mail.gmail.com>
Message-ID: <b81b524eadac8803c610a8ea0d04edbf383cc795.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 09.12.2020, 09:19 -0800 schrieb Iavor Diatchki:
> On Wed, Dec 9, 2020 at 5:40 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
> > What I also got from this discussion was learning why sometimes a
> > `where foo = 1000` works at different number types, and sometimes not.
> > It depends on whether I am using GADTs or TypeFamilies somewhere in the
> > file! Who’d have thought…
> > 
> 
> Actually `where foo = 1000` wouldn't be affected by `MonoLocalBinds` (but would be by the `MonomorphsimRestriction`, fun right :-)  ).
> `MonoLocalBinds` only affects local bindings that depend on something from a pattern (i.e., declaration that you can't
> just move to the top level because they depend on something locally bound)

Indeed! I confess ignorance…


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



From rae at richarde.dev  Wed Dec  9 18:48:33 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 9 Dec 2020 18:48:33 +0000
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
Message-ID: <010f017648d56527-7295fdc2-1783-4660-8c84-ca4115868693-000000@us-east-2.amazonses.com>



> On Dec 9, 2020, at 6:17 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>  Or would you rather see these stay in their standalone extensions forever? (which I would find, personally, rather alarming)

I'm attacking from the standpoint that these will be extensions forever -- or, at least until we have a specification of them. (Amazingly, we don't have a specification for either one, right now.) Haskell will always have new learners, and I think it's reasonable to guard some advanced features behind extensions, always. Perhaps we need to simplify the space of extensions (including a FancyTypes or DependentTypes extension), but I'd be happy to see these features guarded into perpetuity.

About specification: The OutsideIn paper includes an overly-generous specification of GADTs, but not a precise one. I am unaware of a precise specification of what programs are accepted with GADTs, beyond the GHC implementation. Along similar lines, there is no specification of how type families reduce. (For example, what happens with `type family F where F = If True Int F`?)

> How is a partial type signature a partially-written program? Does the absence of type signature on a binding make a program partially written? Because a partial type signature is more than no signature at all, so it should be considered less partial at least.

This is a good point. I see partial type signatures as a development tool, where a user elides part of a type signature in order to get the compiler to provide information on how to fill it in. But maybe that's not the best viewpoint.

Richard

From trupill at gmail.com  Wed Dec  9 20:17:49 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 9 Dec 2020 15:17:49 -0500
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
Message-ID: <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>

 Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome
should be. The ghc-proposals README states that:

Acceptance of the proposal implies that the implementation will be accepted
> into GHC provided it is well-engineered, well-documented, and does not
> complicate the code-base too much.
>

Most of the Committee seems to lean towards “this seems OK right now, but
we don’t want to be locked” or “mark this as experimental”. However,
there’s no such notion as “accept as experimental”. Furthermore, as it
stands the proposal gives some syntax, and then asks any new extensions to
use that syntax; so it cannot be completely thought as a feature by itself.

Regards,
Alejandro

On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:

> It's always possible to change. I don't think accepting a proposal means
> (or ought to mean) that we are locked into anything. Accepting a proposal
> means that we won't oppose a design-related argument to a PR that
> implements (part or all of) an accepted proposal.
>
> I don't know how to quantify the degree of confidence that we have in the
> stability of a proposal. Here we are all saying: this is better than
> anything so far, and we rather need something like this to be a thing, but
> it's really a shot in the dark. And this lack of confidence will be
> reflected in the manual description. But even if we are confident in the
> stability of a proposal, it may very well happen that it changes
> dramatically, even soon.
>
> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> I’ve replied on GitHub.  Generally in favour.  But mark it as
>> experimental… I don’t want to be locked into “we decided on this in Dec
>> 2020 so now it’s too late”.  WE can learn from experience.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>> Serrano Mena
>> *Sent:* 03 December 2020 20:17
>> *To:* Richard Eisenberg <rae at richarde.dev>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>> Recommendation: Acceptance
>>
>>
>>
>> Dear Committee,
>>
>>
>>
>> Richard has requested for us to consider the new version of this
>> proposal. As opposed to the previous version, this one is only about
>> reserving syntax for “modifiers”, which at the beginning would be used for
>> things like linearity or matchability of arrows.
>>
>>
>>
>> I think this is a good proposal, and one which would save us from
>> re-considering syntax for every possible extension (and if linearity
>> appears before the arrow and matchability after it, where would a future
>> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>> To my surprise, I found myself leaning against. So I updated and
>> simplified the proposal to remove Modifier. This makes modifiers a bit more
>> magical, but more likely to actually work in practice. The type inference
>> story previously may have been intractable.
>>
>>
>>
>> I've requested that the committee consider the updates in parallel with
>> community feedback.
>>
>>
>>
>> Thanks,
>>
>> Richard
>>
>>
>>
>> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>>
>>
>> After some discussion in the GitHub thread, changes are going to arrive
>> to the proposal. I think the best is to send the proposal back to the
>> “Needs revision” state.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>>
>> I left a few comments and questions on the PR itself, but I'm leaning
>> towards rejecting the proposal in its current form as well. This doesn't
>> (yet) feel like a generic mechanism, in particular because the only
>> modifier that has been specified would be deeply wired into GHC itself.
>>
>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>
>> Hi,
>>
>>
>>
>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>
>> Mena:
>>
>> > Dear all,
>>
>> > This proposal suggests adding syntax for a general notion of
>>
>> > modifiers, like the ones we’ve been talking about lately affecting
>>
>> > linearity or matchability of arrows. For example, if linear types and
>>
>> > unsaturated families are accepted as they stand, we would have `Int
>>
>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>
>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>
>> >
>>
>> > Since the amount of modifiers is likely to increase in the future, I
>>
>> > think it’s a great idea to agree and reserve such syntax, instead of
>>
>> > coming up with different ways on each proposal. I thus recommend
>>
>> > acceptance of this proposal.
>>
>> >
>>
>> > The proposal itself:
>>
>> > (1) introduces syntax for modifiers in types and defines how to
>>
>> > type/kind check them,
>>
>> > (2) reserved such syntax for other uses in declarations and terms.
>>
>> >
>>
>> > I think the proposal still has its merits only with (1), even though
>>
>> > I lean towards accepting both parts of it.
>>
>>
>>
>> I like the idea of reserving syntax here, but parts of the proposal
>>
>> smell a bit like premature generalization to me. Are we confident that
>>
>> all annotations we eventually would like to use with this feature can
>>
>> be expressed as types of a kind that is an instance of Modifier? Or
>>
>> should we reserve the ability to have annotations that don't fit that
>>
>> model?
>>
>>
>>
>> Would we ever have annotation that may affect phases earlier than than
>>
>> typechecking? What if we want to use (%type e) and (%data e) to help
>>
>> with the SingleNamepace issues? Look like useful annotations to me, but
>>
>> I am not sure if they fit the framework proposed here.
>>
>>
>>
>> The fact that we special-case %1 supports that.
>>
>>
>>
>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>
>> isn't that indication that using the type system to model the various
>>
>> modifiers might be the wrong tool?
>>
>>
>>
>> I wonder if there is a way where the %(…) on it’s own only reserve
>>
>> syntax, and the various uses of that syntax can be disambiguated
>>
>> _statically_ based on the content of ….
>>
>>
>>
>> Not great syntax, because not concise, enough, but morally I’d feel
>>
>> more at ease with
>>
>>
>>
>>   Int %(multiplicity Many) -> Int
>>
>>   Int %(multiplicity 1) -> Int
>>
>>   Int %(multiplicity m) -> Int
>>
>>
>>
>> where multiplicity is a modifier keyword, to express the existing
>>
>> features (including implicit generalization of m). Then we can extend
>>
>> this to
>>
>>
>>
>>   Int %oneShot -> Int
>>
>>
>>
>> and
>>
>>
>>
>>   Int %(matchability M) -> Int
>>
>>
>>
>> and maybe even
>>
>>
>>
>>   foo (%type [a]) -- where foo :: forall a -> ()
>>
>>
>>
>> which is a modifier that
>>
>>
>>
>>
>>
>> So at the moment, I am inclined to reject this proposal, until I am
>>
>> convinced that we are not painting ourselves into a “all modifiers are
>>
>> types of special kinds and that’s all the syntax and behaviour we ever
>>
>> need” corner.
>>
>>
>>
>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>
>> should we also be able to annotate other infix operators, i.e.
>>
>>
>>
>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>
>>   infixexp ::= lexp {modifier} qop infixexp
>>
>>
>>
>>
>>
>>
>>
>> Cheers,
>>
>> Joachim
>>
>>
>>
>>
>>
>> --
>>
>> Joachim Breitner
>>
>>   mail at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> ghc-steering-committee mailing list
>>
>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/03a1c545/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Dec 10 08:05:52 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 10 Dec 2020 09:05:52 +0100
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
Message-ID: <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>

That was the point of my previous email: accept, and accept-as-experimental
are actually one and the same.

What Simon is driving at, I think, is: depending on what the proposal is
about, we want to apply more or less strict standard of acceptance (if a
proposal is about fixing something in an existing feature, then we better
be rather sure that it is indeed an improvement; but if it's about adding
something new in an untrodden territory, then we can't really be sure, and
it's worth experimenting with).

On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Dear all,
> As the shepherd of this proposal, I’m quite confused about what the
> outcome should be. The ghc-proposals README states that:
>
> Acceptance of the proposal implies that the implementation will be
>> accepted into GHC provided it is well-engineered, well-documented, and does
>> not complicate the code-base too much.
>>
>
> Most of the Committee seems to lean towards “this seems OK right now, but
> we don’t want to be locked” or “mark this as experimental”. However,
> there’s no such notion as “accept as experimental”. Furthermore, as it
> stands the proposal gives some syntax, and then asks any new extensions to
> use that syntax; so it cannot be completely thought as a feature by itself.
>
> Regards,
> Alejandro
>
> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> It's always possible to change. I don't think accepting a proposal means
>> (or ought to mean) that we are locked into anything. Accepting a proposal
>> means that we won't oppose a design-related argument to a PR that
>> implements (part or all of) an accepted proposal.
>>
>> I don't know how to quantify the degree of confidence that we have in the
>> stability of a proposal. Here we are all saying: this is better than
>> anything so far, and we rather need something like this to be a thing, but
>> it's really a shot in the dark. And this lack of confidence will be
>> reflected in the manual description. But even if we are confident in the
>> stability of a proposal, it may very well happen that it changes
>> dramatically, even soon.
>>
>> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>>> I’ve replied on GitHub.  Generally in favour.  But mark it as
>>> experimental… I don’t want to be locked into “we decided on this in Dec
>>> 2020 so now it’s too late”.  WE can learn from experience.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>> Serrano Mena
>>> *Sent:* 03 December 2020 20:17
>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>>> Recommendation: Acceptance
>>>
>>>
>>>
>>> Dear Committee,
>>>
>>>
>>>
>>> Richard has requested for us to consider the new version of this
>>> proposal. As opposed to the previous version, this one is only about
>>> reserving syntax for “modifiers”, which at the beginning would be used for
>>> things like linearity or matchability of arrows.
>>>
>>>
>>>
>>> I think this is a good proposal, and one which would save us from
>>> re-considering syntax for every possible extension (and if linearity
>>> appears before the arrow and matchability after it, where would a future
>>> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>> To my surprise, I found myself leaning against. So I updated and
>>> simplified the proposal to remove Modifier. This makes modifiers a bit more
>>> magical, but more likely to actually work in practice. The type inference
>>> story previously may have been intractable.
>>>
>>>
>>>
>>> I've requested that the committee consider the updates in parallel with
>>> community feedback.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Richard
>>>
>>>
>>>
>>> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> After some discussion in the GitHub thread, changes are going to arrive
>>> to the proposal. I think the best is to send the proposal back to the
>>> “Needs revision” state.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>>>
>>> I left a few comments and questions on the PR itself, but I'm leaning
>>> towards rejecting the proposal in its current form as well. This doesn't
>>> (yet) feel like a generic mechanism, in particular because the only
>>> modifier that has been specified would be deeply wired into GHC itself.
>>>
>>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>>
>>> Mena:
>>>
>>> > Dear all,
>>>
>>> > This proposal suggests adding syntax for a general notion of
>>>
>>> > modifiers, like the ones we’ve been talking about lately affecting
>>>
>>> > linearity or matchability of arrows. For example, if linear types and
>>>
>>> > unsaturated families are accepted as they stand, we would have `Int
>>>
>>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>>
>>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>>
>>> >
>>>
>>> > Since the amount of modifiers is likely to increase in the future, I
>>>
>>> > think it’s a great idea to agree and reserve such syntax, instead of
>>>
>>> > coming up with different ways on each proposal. I thus recommend
>>>
>>> > acceptance of this proposal.
>>>
>>> >
>>>
>>> > The proposal itself:
>>>
>>> > (1) introduces syntax for modifiers in types and defines how to
>>>
>>> > type/kind check them,
>>>
>>> > (2) reserved such syntax for other uses in declarations and terms.
>>>
>>> >
>>>
>>> > I think the proposal still has its merits only with (1), even though
>>>
>>> > I lean towards accepting both parts of it.
>>>
>>>
>>>
>>> I like the idea of reserving syntax here, but parts of the proposal
>>>
>>> smell a bit like premature generalization to me. Are we confident that
>>>
>>> all annotations we eventually would like to use with this feature can
>>>
>>> be expressed as types of a kind that is an instance of Modifier? Or
>>>
>>> should we reserve the ability to have annotations that don't fit that
>>>
>>> model?
>>>
>>>
>>>
>>> Would we ever have annotation that may affect phases earlier than than
>>>
>>> typechecking? What if we want to use (%type e) and (%data e) to help
>>>
>>> with the SingleNamepace issues? Look like useful annotations to me, but
>>>
>>> I am not sure if they fit the framework proposed here.
>>>
>>>
>>>
>>> The fact that we special-case %1 supports that.
>>>
>>>
>>>
>>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>>
>>> isn't that indication that using the type system to model the various
>>>
>>> modifiers might be the wrong tool?
>>>
>>>
>>>
>>> I wonder if there is a way where the %(…) on it’s own only reserve
>>>
>>> syntax, and the various uses of that syntax can be disambiguated
>>>
>>> _statically_ based on the content of ….
>>>
>>>
>>>
>>> Not great syntax, because not concise, enough, but morally I’d feel
>>>
>>> more at ease with
>>>
>>>
>>>
>>>   Int %(multiplicity Many) -> Int
>>>
>>>   Int %(multiplicity 1) -> Int
>>>
>>>   Int %(multiplicity m) -> Int
>>>
>>>
>>>
>>> where multiplicity is a modifier keyword, to express the existing
>>>
>>> features (including implicit generalization of m). Then we can extend
>>>
>>> this to
>>>
>>>
>>>
>>>   Int %oneShot -> Int
>>>
>>>
>>>
>>> and
>>>
>>>
>>>
>>>   Int %(matchability M) -> Int
>>>
>>>
>>>
>>> and maybe even
>>>
>>>
>>>
>>>   foo (%type [a]) -- where foo :: forall a -> ()
>>>
>>>
>>>
>>> which is a modifier that
>>>
>>>
>>>
>>>
>>>
>>> So at the moment, I am inclined to reject this proposal, until I am
>>>
>>> convinced that we are not painting ourselves into a “all modifiers are
>>>
>>> types of special kinds and that’s all the syntax and behaviour we ever
>>>
>>> need” corner.
>>>
>>>
>>>
>>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>>
>>> should we also be able to annotate other infix operators, i.e.
>>>
>>>
>>>
>>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>>
>>>   infixexp ::= lexp {modifier} qop infixexp
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Joachim
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Joachim Breitner
>>>
>>>   mail at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195063362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kMw%2BvlOxw4ketBttUdHI1zbAL1SyUFduoR7ac54uLrE%3D&reserved=0>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> ghc-steering-committee mailing list
>>>
>>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195073315%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zlRcj7FjskXnYJDMtX5Wj8Ognw0mPSR1PVG0XK4RNQ4%3D&reserved=0>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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%7C70050d899124429d0d5a08d897c862a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637426234195083273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zxJsZFQYUe4Yu5bjjPfZKC3NQUmrVcEuU7DjV7lhe0g%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/8fff8dc9/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Dec 10 08:18:31 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 10 Dec 2020 09:18:31 +0100
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017648d56527-7295fdc2-1783-4660-8c84-ca4115868693-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
 <010f017648d56527-7295fdc2-1783-4660-8c84-ca4115868693-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=JqRin+v8F2cMwEXqT7J35AkYnBTvwqbc2J=F5NhS0Xw@mail.gmail.com>

> On Dec 9, 2020, at 6:17 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >  Or would you rather see these stay in their standalone extensions
> forever? (which I would find, personally, rather alarming)
>
> I'm attacking from the standpoint that these will be extensions forever --
> or, at least until we have a specification of them. (Amazingly, we don't
> have a specification for either one, right now.) Haskell will always have
> new learners, and I think it's reasonable to guard some advanced features
> behind extensions, always. Perhaps we need to simplify the space of
> extensions (including a FancyTypes or DependentTypes extension), but I'd be
> happy to see these features guarded into perpetuity.
>
> About specification: The OutsideIn paper includes an overly-generous
> specification of GADTs, but not a precise one. I am unaware of a precise
> specification of what programs are accepted with GADTs, beyond the GHC
> implementation. Along similar lines, there is no specification of how type
> families reduce. (For example, what happens with `type family F where F =
> If True Int F`?)
>
This discussion is morphing into something bigger, which increasingly seems
will be a subject for the year to come (as opposed to now). There appears
to be a fairly strong divide on this subject.

> How is a partial type signature a partially-written program? Does the
> absence of type signature on a binding make a program partially written?
> Because a partial type signature is more than no signature at all, so it
> should be considered less partial at least.
>
> This is a good point. I see partial type signatures as a development tool,
> where a user elides part of a type signature in order to get the compiler
> to provide information on how to fill it in. But maybe that's not the best
> viewpoint.
>
I usually think that development tools are better handled with warnings.
That being said, if what we are looking at is elaboration, then probably
errors make sense (just like type holes make sense), though warnings work
quite well too. But if we are looking at “I’ll do this later” then warnings
are the only solution. Plus, there is a third usage of partial type
signatures which are: I really want to specify part of this type signature,
for this is where the information is (and maybe the rest is long and would
distract from the point). This latter part I use frequently in type
applications, for instance, where it is always allowed.

Maybe one of the difficulties about partial type signatures is that it is
not clear how to separate these three aspects. But I still think that
PartialTypeSignature is perfectly serviceable. And could be improved by
tuning the warning more as per this issue I once wrote and never got around
to implement.

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

<interactive>:3:6: warning: [-Wpartial-type-signatures]
    * Found type wildcard `_' standing for `Integer'
    * In the type `_ -> _'
      In the type signature: f :: _ -> _

<interactive>:3:11: warning: [-Wpartial-type-signatures]
    * Found type wildcard `_' standing for `Integer'
    * In the type `_ -> _'
      In the type signature: f :: _ -> _
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/5f609da1/attachment.html>

From simonpj at microsoft.com  Thu Dec 10 08:59:02 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Dec 2020 08:59:02 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
Message-ID: <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>

That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
Objectively, yes.  But I think it helps users to advertise a feature as experimental.  It’s a signal to users that this feature is, well, experimental.  It is more likely to change.
It’s only an indication not a clear distinction.  But I find it helpful.
For me, it also reflects how I evaluate the proposal.  For a change to a well-established feature, we have a lot of experience in how people use that feature.
For experimental features we don’t.  Example: defaulting for matchability for unsaturated type families.  We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting.  We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
Simon

From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Sent: 10 December 2020 08:06
To: Alejandro Serrano Mena <trupill at gmail.com>
Cc: Richard Eisenberg <rae at richarde.dev>; ghc-steering-committee at haskell.org; Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance

That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.

What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).

On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:
Dear all,
As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:

Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.

Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.

Regards,
Alejandro
On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.

I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.

On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
I’ve replied on GitHub.  Generally in favour.  But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”.  WE can learn from experience.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
Sent: 03 December 2020 20:17
To: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance

Dear Committee,

Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.

I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.

Regards,
Alejandro

On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.

I've requested that the committee consider the updates in parallel with community feedback.

Thanks,
Richard

On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.

Regards,
Alejandro

On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.

On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
Hi,

Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
Mena:
> Dear all,
> This proposal suggests adding syntax for a general notion of
> modifiers, like the ones we’ve been talking about lately affecting
> linearity or matchability of arrows. For example, if linear types and
> unsaturated families are accepted as they stand, we would have `Int
> #1 -> @U Bool` (or something like that), whereas with this proposal
> we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>
> Since the amount of modifiers is likely to increase in the future, I
> think it’s a great idea to agree and reserve such syntax, instead of
> coming up with different ways on each proposal. I thus recommend
> acceptance of this proposal.
>
> The proposal itself:
> (1) introduces syntax for modifiers in types and defines how to
> type/kind check them,
> (2) reserved such syntax for other uses in declarations and terms.
>
> I think the proposal still has its merits only with (1), even though
> I lean towards accepting both parts of it.

I like the idea of reserving syntax here, but parts of the proposal
smell a bit like premature generalization to me. Are we confident that
all annotations we eventually would like to use with this feature can
be expressed as types of a kind that is an instance of Modifier? Or
should we reserve the ability to have annotations that don't fit that
model?

Would we ever have annotation that may affect phases earlier than than
typechecking? What if we want to use (%type e) and (%data e) to help
with the SingleNamepace issues? Look like useful annotations to me, but
I am not sure if they fit the framework proposed here.

The fact that we special-case %1 supports that.

The proposal explicitly has to state “No modifier polymorphism!”. But
isn't that indication that using the type system to model the various
modifiers might be the wrong tool?

I wonder if there is a way where the %(…) on it’s own only reserve
syntax, and the various uses of that syntax can be disambiguated
_statically_ based on the content of ….

Not great syntax, because not concise, enough, but morally I’d feel
more at ease with

  Int %(multiplicity Many) -> Int
  Int %(multiplicity 1) -> Int
  Int %(multiplicity m) -> Int

where multiplicity is a modifier keyword, to express the existing
features (including implicit generalization of m). Then we can extend
this to

  Int %oneShot -> Int

and

  Int %(matchability M) -> Int

and maybe even

  foo (%type [a]) -- where foo :: forall a -> ()

which is a modifier that


So at the moment, I am inclined to reject this proposal, until I am
convinced that we are not painting ourselves into a “all modifiers are
types of special kinds and that’s all the syntax and behaviour we ever
need” corner.

Minor detail: If we can annotate infix use of the (->) “type operator”,
should we also be able to annotate other infix operators, i.e.

  constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
  infixexp ::= lexp {modifier} qop infixexp



Cheers,
Joachim


--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/4875f28f/attachment-0001.html>

From trupill at gmail.com  Thu Dec 10 09:29:11 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 10 Dec 2020 01:29:11 -0800
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>

 Should we mark them as “accepted” with the following text?

The Committee accepts this proposal as experimental. This means that the
> Committee expects changes to this feature in the future, maybe as the
> result of other accepted proposals.
>

If you agree, then we can accept this proposal once a little remaining
issue with the grammar has been clarified.

Regards,
Alejandro


On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> That was the point of my previous email: accept, and
> accept-as-experimental are actually one and the same.
>
> Objectively, yes.  But I think it helps users to advertise a feature as
> experimental.  It’s a signal to users that this feature is, well,
> experimental.  It is more likely to change.
>
> It’s only an indication not a clear distinction.  But I find it helpful.
>
> For me, it also reflects how I evaluate the proposal.  For a change to a
> well-established feature, we have a lot of experience in how people use
> that feature.
>
> For experimental features we don’t.  Example: defaulting for matchability
> for unsaturated type families.  We don’t have unsaturated type families
> right now, so we don’t have any code that uses them, and hence zero
> in-the-wild experience about matchability defaulting.  We shouldn’t spend
> ages arguing the toss – just trust Csongor’s judgement and give it a try,
> but advertising that details may change.
>
> Simon
>
>
>
> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Sent:* 10 December 2020 08:06
> *To:* Alejandro Serrano Mena <trupill at gmail.com>
> *Cc:* Richard Eisenberg <rae at richarde.dev>;
> ghc-steering-committee at haskell.org; Simon Peyton Jones <
> simonpj at microsoft.com>
> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
> Recommendation: Acceptance
>
>
>
> That was the point of my previous email: accept, and
> accept-as-experimental are actually one and the same.
>
>
>
> What Simon is driving at, I think, is: depending on what the proposal is
> about, we want to apply more or less strict standard of acceptance (if a
> proposal is about fixing something in an existing feature, then we better
> be rather sure that it is indeed an improvement; but if it's about adding
> something new in an untrodden territory, then we can't really be sure, and
> it's worth experimenting with).
>
>
>
> On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> Dear all,
>
> As the shepherd of this proposal, I’m quite confused about what the
> outcome should be. The ghc-proposals README states that:
>
>
>
> Acceptance of the proposal implies that the implementation will be
> accepted into GHC provided it is well-engineered, well-documented, and does
> not complicate the code-base too much.
>
>
>
> Most of the Committee seems to lean towards “this seems OK right now, but
> we don’t want to be locked” or “mark this as experimental”. However,
> there’s no such notion as “accept as experimental”. Furthermore, as it
> stands the proposal gives some syntax, and then asks any new extensions to
> use that syntax; so it cannot be completely thought as a feature by itself.
>
>
>
> Regards,
>
> Alejandro
>
> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> It's always possible to change. I don't think accepting a proposal means
> (or ought to mean) that we are locked into anything. Accepting a proposal
> means that we won't oppose a design-related argument to a PR that
> implements (part or all of) an accepted proposal.
>
>
>
> I don't know how to quantify the degree of confidence that we have in the
> stability of a proposal. Here we are all saying: this is better than
> anything so far, and we rather need something like this to be a thing, but
> it's really a shot in the dark. And this lack of confidence will be
> reflected in the manual description. But even if we are confident in the
> stability of a proposal, it may very well happen that it changes
> dramatically, even soon.
>
>
>
> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> I’ve replied on GitHub.  Generally in favour.  But mark it as
> experimental… I don’t want to be locked into “we decided on this in Dec
> 2020 so now it’s too late”.  WE can learn from experience.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 03 December 2020 20:17
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
> Recommendation: Acceptance
>
>
>
> Dear Committee,
>
>
>
> Richard has requested for us to consider the new version of this proposal.
> As opposed to the previous version, this one is only about reserving syntax
> for “modifiers”, which at the beginning would be used for things like
> linearity or matchability of arrows.
>
>
>
> I think this is a good proposal, and one which would save us from
> re-considering syntax for every possible extension (and if linearity
> appears before the arrow and matchability after it, where would a future
> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>
> To my surprise, I found myself leaning against. So I updated and
> simplified the proposal to remove Modifier. This makes modifiers a bit more
> magical, but more likely to actually work in practice. The type inference
> story previously may have been intractable.
>
>
>
> I've requested that the committee consider the updates in parallel with
> community feedback.
>
>
>
> Thanks,
>
> Richard
>
>
>
> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>
>
> After some discussion in the GitHub thread, changes are going to arrive to
> the proposal. I think the best is to send the proposal back to the “Needs
> revision” state.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>
> I left a few comments and questions on the PR itself, but I'm leaning
> towards rejecting the proposal in its current form as well. This doesn't
> (yet) feel like a generic mechanism, in particular because the only
> modifier that has been specified would be deeply wired into GHC itself.
>
> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>
> Hi,
>
>
>
> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>
> Mena:
>
> > Dear all,
>
> > This proposal suggests adding syntax for a general notion of
>
> > modifiers, like the ones we’ve been talking about lately affecting
>
> > linearity or matchability of arrows. For example, if linear types and
>
> > unsaturated families are accepted as they stand, we would have `Int
>
> > #1 -> @U Bool` (or something like that), whereas with this proposal
>
> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>
> >
>
> > Since the amount of modifiers is likely to increase in the future, I
>
> > think it’s a great idea to agree and reserve such syntax, instead of
>
> > coming up with different ways on each proposal. I thus recommend
>
> > acceptance of this proposal.
>
> >
>
> > The proposal itself:
>
> > (1) introduces syntax for modifiers in types and defines how to
>
> > type/kind check them,
>
> > (2) reserved such syntax for other uses in declarations and terms.
>
> >
>
> > I think the proposal still has its merits only with (1), even though
>
> > I lean towards accepting both parts of it.
>
>
>
> I like the idea of reserving syntax here, but parts of the proposal
>
> smell a bit like premature generalization to me. Are we confident that
>
> all annotations we eventually would like to use with this feature can
>
> be expressed as types of a kind that is an instance of Modifier? Or
>
> should we reserve the ability to have annotations that don't fit that
>
> model?
>
>
>
> Would we ever have annotation that may affect phases earlier than than
>
> typechecking? What if we want to use (%type e) and (%data e) to help
>
> with the SingleNamepace issues? Look like useful annotations to me, but
>
> I am not sure if they fit the framework proposed here.
>
>
>
> The fact that we special-case %1 supports that.
>
>
>
> The proposal explicitly has to state “No modifier polymorphism!”. But
>
> isn't that indication that using the type system to model the various
>
> modifiers might be the wrong tool?
>
>
>
> I wonder if there is a way where the %(…) on it’s own only reserve
>
> syntax, and the various uses of that syntax can be disambiguated
>
> _statically_ based on the content of ….
>
>
>
> Not great syntax, because not concise, enough, but morally I’d feel
>
> more at ease with
>
>
>
>   Int %(multiplicity Many) -> Int
>
>   Int %(multiplicity 1) -> Int
>
>   Int %(multiplicity m) -> Int
>
>
>
> where multiplicity is a modifier keyword, to express the existing
>
> features (including implicit generalization of m). Then we can extend
>
> this to
>
>
>
>   Int %oneShot -> Int
>
>
>
> and
>
>
>
>   Int %(matchability M) -> Int
>
>
>
> and maybe even
>
>
>
>   foo (%type [a]) -- where foo :: forall a -> ()
>
>
>
> which is a modifier that
>
>
>
>
>
> So at the moment, I am inclined to reject this proposal, until I am
>
> convinced that we are not painting ourselves into a “all modifiers are
>
> types of special kinds and that’s all the syntax and behaviour we ever
>
> need” corner.
>
>
>
> Minor detail: If we can annotate infix use of the (->) “type operator”,
>
> should we also be able to annotate other infix operators, i.e.
>
>
>
>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>
>   infixexp ::= lexp {modifier} qop infixexp
>
>
>
>
>
>
>
> Cheers,
>
> Joachim
>
>
>
>
>
> --
>
> Joachim Breitner
>
>   mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
>
>
>
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/85b8fb4b/attachment-0001.html>

From marlowsd at gmail.com  Thu Dec 10 09:37:38 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 10 Dec 2020 09:37:38 +0000
Subject: [ghc-steering-committee] A few more pleas
In-Reply-To: <010f017648d56527-7295fdc2-1783-4660-8c84-ca4115868693-000000@us-east-2.amazonses.com>
References: <010f017640763759-508c2737-0997-4b95-aa47-a0f6bb3d0fb4-000000@us-east-2.amazonses.com>
 <f023b7927eb49b1bb31791227acd43c1335b4054.camel@joachim-breitner.de>
 <010f017643eaefb0-95f9f74a-c160-42be-ae9d-0ff1e69d5935-000000@us-east-2.amazonses.com>
 <CAH6fHQnB6i4r57YELeq6Q130YtjiLV2mkG+mHMGCsKK98maT6Q@mail.gmail.com>
 <010f017648d56527-7295fdc2-1783-4660-8c84-ca4115868693-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPJ8jphnqDNygBHXndQ6h7EFTU-kpFhvFEE4+6CnyDJL9g@mail.gmail.com>

On Wed, 9 Dec 2020 at 18:48, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> > On Dec 9, 2020, at 6:17 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >  Or would you rather see these stay in their standalone extensions
> forever? (which I would find, personally, rather alarming)
>
> I'm attacking from the standpoint that these will be extensions forever --
> or, at least until we have a specification of them. (Amazingly, we don't
> have a specification for either one, right now.) Haskell will always have
> new learners, and I think it's reasonable to guard some advanced features
> behind extensions, always. Perhaps we need to simplify the space of
> extensions (including a FancyTypes or DependentTypes extension), but I'd be
> happy to see these features guarded into perpetuity.
>

So let me separate the two points here:

   - Extensions without a specification shouldn't be part of the default
   language. I'd agree that they certainly shouldn't be part of the Haskell
   *standard*, but the bar for a GHC extension, even one that is enabled by
   default, is lower than this I think. (Indeed, one might point out that
   there wasn't a proper specification of the Haskell type system when the
   standard was published)
   - Whether advanced features like TypeFamilies and GADTs should need to
   be explicitly enabled. I disagree with this:


   1. To a large degree these features already *are* guarded in the sense
      that you have to explicitly define a type family or a GADT.
Having to jump
      through the extra hoop of adding a LANGUAGE pragma is
unnecessary friction.
      Yes there are exceptions to this - needing a LANGUAGE pragma to
      pattern-match on a GADT for example - I also think this is unnecessary
      friction, because you can understand what the pattern-match does
by looking
      at the definition of the type. Incidentally you don't need {-# LANGUAGE
      TypeFamilies #-} to use a type family in a type, so we're not very
      consistent here.
      2. I don't think the extra signal of a LANGUAGE pragma or a flag in
      the Cabal file really adds anything useful for extensions that
are largely
      stable. As a user you don't go looking for these things when reading code
      so that you can understand what dialect the code is written in, we just
      read code. There needs to be a common dialect as far as possible.

Having said all this, there definitely *are* cases where you might
want to *disable
*fancy type features. At FB we have a large codebase of DSL code that is
used by engineers with a wide range of Haskell experience, so we want to
keep the level of fancy-types to a minimum. This is like the "beginner
Haskell" use case where we want to be able to turn off a lot of advanced
features to flatten the learning curve. This is an important use case that
GHC should continue to support by having a way to turn off extensions, but
I don't think it means that the default mode should also have these
extensions disabled.

Cheers
Simon


>
> About specification: The OutsideIn paper includes an overly-generous
> specification of GADTs, but not a precise one. I am unaware of a precise
> specification of what programs are accepted with GADTs, beyond the GHC
> implementation. Along similar lines, there is no specification of how type
> families reduce. (For example, what happens with `type family F where F =
> If True Int F`?)
>
> > How is a partial type signature a partially-written program? Does the
> absence of type signature on a binding make a program partially written?
> Because a partial type signature is more than no signature at all, so it
> should be considered less partial at least.
>
> This is a good point. I see partial type signatures as a development tool,
> where a user elides part of a type signature in order to get the compiler
> to provide information on how to fill it in. But maybe that's not the best
> viewpoint.
>
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/54e03840/attachment.html>

From rae at richarde.dev  Fri Dec 11 20:35:20 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 11 Dec 2020 20:35:20 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
Message-ID: <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>

Sorry -- I've lost track here a bit. What's the issue with the grammar?

I'm quite happy to label this experimental. The key aspect of the proposal is just to outline a way forward with adding syntax.

Richard

> On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Should we mark them as “accepted” with the following text?
> 
> The Committee accepts this proposal as experimental. This means that the Committee expects changes to this feature in the future, maybe as the result of other accepted proposals.
> 
> If you agree, then we can accept this proposal once a little remaining issue with the grammar has been clarified.
> 
> Regards,
> Alejandro
> 
> 
> On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
> 
> Objectively, yes.  But I think it helps users to advertise a feature as experimental.  It’s a signal to users that this feature is, well, experimental.  It is more likely to change.
> 
> It’s only an indication not a clear distinction.  But I find it helpful.
> 
> For me, it also reflects how I evaluate the proposal.  For a change to a well-established feature, we have a lot of experience in how people use that feature. 
> 
> For experimental features we don’t.  Example: defaulting for matchability for unsaturated type families.  We don’t have unsaturated type families right now, so we don’t have any code that uses them, and hence zero in-the-wild experience about matchability defaulting.  We shouldn’t spend ages arguing the toss – just trust Csongor’s judgement and give it a try, but advertising that details may change.
> 
> Simon
> 
>  
> From: Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> 
> Sent: 10 December 2020 08:06
> To: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>>
> Cc: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>; Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
> 
>  
> That was the point of my previous email: accept, and accept-as-experimental are actually one and the same.
> 
>  
> What Simon is driving at, I think, is: depending on what the proposal is about, we want to apply more or less strict standard of acceptance (if a proposal is about fixing something in an existing feature, then we better be rather sure that it is indeed an improvement; but if it's about adding something new in an untrodden territory, then we can't really be sure, and it's worth experimenting with).
> 
>  
> On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> 
> Dear all,
> 
> As the shepherd of this proposal, I’m quite confused about what the outcome should be. The ghc-proposals README states that:
> 
>  
> Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
> 
>  
> Most of the Committee seems to lean towards “this seems OK right now, but we don’t want to be locked” or “mark this as experimental”. However, there’s no such notion as “accept as experimental”. Furthermore, as it stands the proposal gives some syntax, and then asks any new extensions to use that syntax; so it cannot be completely thought as a feature by itself.
> 
>  
> Regards,
> 
> Alejandro
> 
> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
> It's always possible to change. I don't think accepting a proposal means (or ought to mean) that we are locked into anything. Accepting a proposal means that we won't oppose a design-related argument to a PR that implements (part or all of) an accepted proposal.
> 
>  
> I don't know how to quantify the degree of confidence that we have in the stability of a proposal. Here we are all saying: this is better than anything so far, and we rather need something like this to be a thing, but it's really a shot in the dark. And this lack of confidence will be reflected in the manual description. But even if we are confident in the stability of a proposal, it may very well happen that it changes dramatically, even soon.
> 
>  
> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> 
> I’ve replied on GitHub.  Generally in favour.  But mark it as experimental… I don’t want to be locked into “we decided on this in Dec 2020 so now it’s too late”.  WE can learn from experience.
> 
>  
> Simon
> 
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
> Sent: 03 December 2020 20:17
> To: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance
> 
>  
> Dear Committee,
> 
>  
> Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.
> 
>  
> I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.
> 
>  
> Regards,
> 
> Alejandro
> 
>  
> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.
> 
>  
> I've requested that the committee consider the updates in parallel with community feedback.
> 
>  
> Thanks,
> 
> Richard
> 
>  
> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> 
>  
> After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.
> 
>  
> Regards,
> 
> Alejandro
> 
>  
> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> 
> I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.
> 
> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
> 
> Hi,
> 
>  
> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
> 
> Mena:
> 
> > Dear all,
> 
> > This proposal suggests adding syntax for a general notion of
> 
> > modifiers, like the ones we’ve been talking about lately affecting
> 
> > linearity or matchability of arrows. For example, if linear types and
> 
> > unsaturated families are accepted as they stand, we would have `Int
> 
> > #1 -> @U Bool` (or something like that), whereas with this proposal
> 
> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
> 
> >
> 
> > Since the amount of modifiers is likely to increase in the future, I
> 
> > think it’s a great idea to agree and reserve such syntax, instead of
> 
> > coming up with different ways on each proposal. I thus recommend
> 
> > acceptance of this proposal.
> 
> >
> 
> > The proposal itself:
> 
> > (1) introduces syntax for modifiers in types and defines how to
> 
> > type/kind check them,
> 
> > (2) reserved such syntax for other uses in declarations and terms.
> 
> >
> 
> > I think the proposal still has its merits only with (1), even though
> 
> > I lean towards accepting both parts of it.
> 
>  
> I like the idea of reserving syntax here, but parts of the proposal
> 
> smell a bit like premature generalization to me. Are we confident that
> 
> all annotations we eventually would like to use with this feature can
> 
> be expressed as types of a kind that is an instance of Modifier? Or
> 
> should we reserve the ability to have annotations that don't fit that
> 
> model?
> 
>  
> Would we ever have annotation that may affect phases earlier than than
> 
> typechecking? What if we want to use (%type e) and (%data e) to help
> 
> with the SingleNamepace issues? Look like useful annotations to me, but
> 
> I am not sure if they fit the framework proposed here.
> 
>  
> The fact that we special-case %1 supports that.
> 
>  
> The proposal explicitly has to state “No modifier polymorphism!”. But
> 
> isn't that indication that using the type system to model the various
> 
> modifiers might be the wrong tool?
> 
>  
> I wonder if there is a way where the %(…) on it’s own only reserve
> 
> syntax, and the various uses of that syntax can be disambiguated
> 
> _statically_ based on the content of ….
> 
>  
> Not great syntax, because not concise, enough, but morally I’d feel
> 
> more at ease with
> 
>  
>   Int %(multiplicity Many) -> Int
> 
>   Int %(multiplicity 1) -> Int
> 
>   Int %(multiplicity m) -> Int
> 
>  
> where multiplicity is a modifier keyword, to express the existing
> 
> features (including implicit generalization of m). Then we can extend
> 
> this to
> 
>  
>   Int %oneShot -> Int
> 
>  
> and
> 
>  
>   Int %(matchability M) -> Int
> 
>  
> and maybe even
> 
>  
>   foo (%type [a]) -- where foo :: forall a -> ()
> 
>  
> which is a modifier that
> 
>  
>  
> So at the moment, I am inclined to reject this proposal, until I am
> 
> convinced that we are not painting ourselves into a “all modifiers are
> 
> types of special kinds and that’s all the syntax and behaviour we ever
> 
> need” corner.
> 
>  
> Minor detail: If we can annotate infix use of the (->) “type operator”,
> 
> should we also be able to annotate other infix operators, i.e.
> 
>  
>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
> 
>   infixexp ::= lexp {modifier} qop infixexp
> 
>  
>  
>  
> Cheers,
> 
> Joachim
> 
>  
>  
> --
> 
> Joachim Breitner
> 
>   mail at joachim-breitner.de <mailto:mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
>  
>  
> _______________________________________________
> 
> ghc-steering-committee mailing list
> 
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>  
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>  
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201211/a846d398/attachment-0001.html>

From trupill at gmail.com  Fri Dec 11 21:39:39 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 11 Dec 2020 21:39:39 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
 <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtp1m7hNvnEELryJz9G+JFg4CxXfz0ERJYurvvFPdJJcg@mail.gmail.com>

On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae at richarde.dev> wrote:

> Sorry -- I've lost track here a bit. What's the issue with the grammar?
>

In this comment
https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-741785189
:

Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
> modifiers but not two. Or do I misunderstand the braces? Spell it out please
>

Regards,
Alejandro


> I'm quite happy to label this experimental. The key aspect of the proposal
> is just to outline a way forward with adding syntax.
>
> Richard
>
> On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> Should we mark them as “accepted” with the following text?
>
> The Committee accepts this proposal as experimental. This means that the
>> Committee expects changes to this feature in the future, maybe as the
>> result of other accepted proposals.
>>
>
> If you agree, then we can accept this proposal once a little remaining
> issue with the grammar has been clarified.
>
> Regards,
> Alejandro
>
>
> On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> That was the point of my previous email: accept, and
>> accept-as-experimental are actually one and the same.
>>
>> Objectively, yes.  But I think it helps users to advertise a feature as
>> experimental.  It’s a signal to users that this feature is, well,
>> experimental.  It is more likely to change.
>>
>> It’s only an indication not a clear distinction.  But I find it helpful.
>>
>> For me, it also reflects how I evaluate the proposal.  For a change to a
>> well-established feature, we have a lot of experience in how people use
>> that feature.
>>
>> For experimental features we don’t.  Example: defaulting for matchability
>> for unsaturated type families.  We don’t have unsaturated type families
>> right now, so we don’t have any code that uses them, and hence zero
>> in-the-wild experience about matchability defaulting.  We shouldn’t spend
>> ages arguing the toss – just trust Csongor’s judgement and give it a try,
>> but advertising that details may change.
>>
>> Simon
>>
>>
>> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> *Sent:* 10 December 2020 08:06
>> *To:* Alejandro Serrano Mena <trupill at gmail.com>
>> *Cc:* Richard Eisenberg <rae at richarde.dev>;
>> ghc-steering-committee at haskell.org; Simon Peyton Jones <
>> simonpj at microsoft.com>
>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>> Recommendation: Acceptance
>>
>>
>> That was the point of my previous email: accept, and
>> accept-as-experimental are actually one and the same.
>>
>>
>> What Simon is driving at, I think, is: depending on what the proposal is
>> about, we want to apply more or less strict standard of acceptance (if a
>> proposal is about fixing something in an existing feature, then we better
>> be rather sure that it is indeed an improvement; but if it's about adding
>> something new in an untrodden territory, then we can't really be sure, and
>> it's worth experimenting with).
>>
>>
>> On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Dear all,
>>
>> As the shepherd of this proposal, I’m quite confused about what the
>> outcome should be. The ghc-proposals README states that:
>>
>>
>> Acceptance of the proposal implies that the implementation will be
>> accepted into GHC provided it is well-engineered, well-documented, and does
>> not complicate the code-base too much.
>>
>>
>>
>> Most of the Committee seems to lean towards “this seems OK right now, but
>> we don’t want to be locked” or “mark this as experimental”. However,
>> there’s no such notion as “accept as experimental”. Furthermore, as it
>> stands the proposal gives some syntax, and then asks any new extensions to
>> use that syntax; so it cannot be completely thought as a feature by itself.
>>
>>
>> Regards,
>>
>> Alejandro
>>
>> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> It's always possible to change. I don't think accepting a proposal means
>> (or ought to mean) that we are locked into anything. Accepting a proposal
>> means that we won't oppose a design-related argument to a PR that
>> implements (part or all of) an accepted proposal.
>>
>>
>> I don't know how to quantify the degree of confidence that we have in the
>> stability of a proposal. Here we are all saying: this is better than
>> anything so far, and we rather need something like this to be a thing, but
>> it's really a shot in the dark. And this lack of confidence will be
>> reflected in the manual description. But even if we are confident in the
>> stability of a proposal, it may very well happen that it changes
>> dramatically, even soon.
>>
>>
>> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>> I’ve replied on GitHub.  Generally in favour.  But mark it as
>> experimental… I don’t want to be locked into “we decided on this in Dec
>> 2020 so now it’s too late”.  WE can learn from experience.
>>
>>
>> Simon
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>> Serrano Mena
>> *Sent:* 03 December 2020 20:17
>> *To:* Richard Eisenberg <rae at richarde.dev>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>> Recommendation: Acceptance
>>
>>
>> Dear Committee,
>>
>>
>> Richard has requested for us to consider the new version of this
>> proposal. As opposed to the previous version, this one is only about
>> reserving syntax for “modifiers”, which at the beginning would be used for
>> things like linearity or matchability of arrows.
>>
>>
>> I think this is a good proposal, and one which would save us from
>> re-considering syntax for every possible extension (and if linearity
>> appears before the arrow and matchability after it, where would a future
>> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>> To my surprise, I found myself leaning against. So I updated and
>> simplified the proposal to remove Modifier. This makes modifiers a bit more
>> magical, but more likely to actually work in practice. The type inference
>> story previously may have been intractable.
>>
>>
>> I've requested that the committee consider the updates in parallel with
>> community feedback.
>>
>>
>> Thanks,
>>
>> Richard
>>
>>
>> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>>
>> After some discussion in the GitHub thread, changes are going to arrive
>> to the proposal. I think the best is to send the proposal back to the
>> “Needs revision” state.
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>>
>> I left a few comments and questions on the PR itself, but I'm leaning
>> towards rejecting the proposal in its current form as well. This doesn't
>> (yet) feel like a generic mechanism, in particular because the only
>> modifier that has been specified would be deeply wired into GHC itself.
>>
>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>
>> Hi,
>>
>>
>>
>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>
>> Mena:
>>
>> > Dear all,
>>
>> > This proposal suggests adding syntax for a general notion of
>>
>> > modifiers, like the ones we’ve been talking about lately affecting
>>
>> > linearity or matchability of arrows. For example, if linear types and
>>
>> > unsaturated families are accepted as they stand, we would have `Int
>>
>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>
>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>
>> >
>>
>> > Since the amount of modifiers is likely to increase in the future, I
>>
>> > think it’s a great idea to agree and reserve such syntax, instead of
>>
>> > coming up with different ways on each proposal. I thus recommend
>>
>> > acceptance of this proposal.
>>
>> >
>>
>> > The proposal itself:
>>
>> > (1) introduces syntax for modifiers in types and defines how to
>>
>> > type/kind check them,
>>
>> > (2) reserved such syntax for other uses in declarations and terms.
>>
>> >
>>
>> > I think the proposal still has its merits only with (1), even though
>>
>> > I lean towards accepting both parts of it.
>>
>>
>>
>> I like the idea of reserving syntax here, but parts of the proposal
>>
>> smell a bit like premature generalization to me. Are we confident that
>>
>> all annotations we eventually would like to use with this feature can
>>
>> be expressed as types of a kind that is an instance of Modifier? Or
>>
>> should we reserve the ability to have annotations that don't fit that
>>
>> model?
>>
>>
>>
>> Would we ever have annotation that may affect phases earlier than than
>>
>> typechecking? What if we want to use (%type e) and (%data e) to help
>>
>> with the SingleNamepace issues? Look like useful annotations to me, but
>>
>> I am not sure if they fit the framework proposed here.
>>
>>
>>
>> The fact that we special-case %1 supports that.
>>
>>
>>
>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>
>> isn't that indication that using the type system to model the various
>>
>> modifiers might be the wrong tool?
>>
>>
>>
>> I wonder if there is a way where the %(…) on it’s own only reserve
>>
>> syntax, and the various uses of that syntax can be disambiguated
>>
>> _statically_ based on the content of ….
>>
>>
>>
>> Not great syntax, because not concise, enough, but morally I’d feel
>>
>> more at ease with
>>
>>
>>
>>   Int %(multiplicity Many) -> Int
>>
>>   Int %(multiplicity 1) -> Int
>>
>>   Int %(multiplicity m) -> Int
>>
>>
>>
>> where multiplicity is a modifier keyword, to express the existing
>>
>> features (including implicit generalization of m). Then we can extend
>>
>> this to
>>
>>
>>
>>   Int %oneShot -> Int
>>
>>
>>
>> and
>>
>>
>>
>>   Int %(matchability M) -> Int
>>
>>
>>
>> and maybe even
>>
>>
>>
>>   foo (%type [a]) -- where foo :: forall a -> ()
>>
>>
>>
>> which is a modifier that
>>
>>
>>
>>
>>
>> So at the moment, I am inclined to reject this proposal, until I am
>>
>> convinced that we are not painting ourselves into a “all modifiers are
>>
>> types of special kinds and that’s all the syntax and behaviour we ever
>>
>> need” corner.
>>
>>
>>
>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>
>> should we also be able to annotate other infix operators, i.e.
>>
>>
>>
>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>
>>   infixexp ::= lexp {modifier} qop infixexp
>>
>>
>>
>>
>>
>>
>>
>> Cheers,
>>
>> Joachim
>>
>>
>>
>>
>>
>> --
>>
>> Joachim Breitner
>>
>>   mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> ghc-steering-committee mailing list
>>
>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201211/5a6d2294/attachment-0001.html>

From mail at joachim-breitner.de  Mon Dec 14 09:21:57 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Dec 2020 10:21:57 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Third week starting
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <72e6fb233b062fe40105e547115702dcb00e1ecc.camel@joachim-breitner.de>

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



From simonpj at microsoft.com  Mon Dec 14 09:30:04 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Dec 2020 09:30:04 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Third week starting
In-Reply-To: <72e6fb233b062fe40105e547115702dcb00e1ecc.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <72e6fb233b062fe40105e547115702dcb00e1ecc.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB022243CE8D81DBB76AEF8B94ADC79@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 09:22
|  To: ghc-steering-committee at 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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C225202ff9f
|  2349e6b4e408d8a011bf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435345381013055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=75V1dlj5UI4jtaC
|  bcrBARq%2F2lxWzxmaApT85U4HElIA%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C225202ff9f2349e
|  6b4e408d8a011bf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374353
|  45381013055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BV4gu6uHGXbkOn7aht
|  pRkh1pK%2BkYswQCi4CKr5whgpE%3D&amp;reserved=0

From mail at joachim-breitner.de  Mon Dec 14 09:39:54 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Dec 2020 10:39:54 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Third week starting
In-Reply-To: <VI1PR83MB022243CE8D81DBB76AEF8B94ADC79@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <72e6fb233b062fe40105e547115702dcb00e1ecc.camel@joachim-breitner.de>
 <VI1PR83MB022243CE8D81DBB76AEF8B94ADC79@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <d54b5c550a2c406171dac2d3e266289ac83439eb.camel@joachim-breitner.de>

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://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Mon Dec 14 10:08:44 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Dec 2020 10:08:44 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Third week starting
In-Reply-To: <d54b5c550a2c406171dac2d3e266289ac83439eb.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <72e6fb233b062fe40105e547115702dcb00e1ecc.camel@joachim-breitner.de>
 <VI1PR83MB022243CE8D81DBB76AEF8B94ADC79@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <d54b5c550a2c406171dac2d3e266289ac83439eb.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02222A45B723C153213E9CE5ADC79@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 09:40
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b654
|  bf2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
|  5356163845164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
|  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E0GKm1ODBAI1%2BdNV
|  95TbOynJOZZNFvjshPsQtGPI28c%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b
|  654bf2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435356163855156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VjZ0WUERIIysxiP
|  xrxxh8coTa4SAHaXzJFstbXuzjVY%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cadd8a2aa1b654bf
|  2a92708d8a014411d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374353
|  56163855156%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tQZXP1BBC7R66QBdQu%2
|  F5CR4NpuM%2Bd7X6GXOjGRPl9pA%3D&amp;reserved=0

From cgibbard at gmail.com  Mon Dec 14 20:22:52 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Mon, 14 Dec 2020 15:22:52 -0500
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <CAF3RzK-nG8W6J6hC-kv4S_vV95kArnqmihEYCBFPyCV8vOUdYA@mail.gmail.com>

Hi! Sorry I missed this thread somehow!

AllowAmbiguousTypes: no
I think this one is mostly okay, but not as a default.

ApplicativeDo: no
My take on this is that either you care about how your computations
decompose into Applicative/Monad operations or you don't. In the first
case, you probably don't want ApplicativeDo because it's basically
unpredictable, and in the second, you probably don't mind having
everything in terms of (>>=).

Arrows: no
Arrow syntax needs work before it will be more useful, and it's not
used often enough as it stands.

BangPatterns: yes
This is useful and wanted commonly enough to warrant making default. I
much preferred it in its original form before it could turn `let` into
`case`, but it's good.

BinaryLiterals: yes
Why not?

BlockArguments: maybe
I don't care so much one way or the other on this one. Personally, I
don't mind writing the $ before a block, and I haven't looked into
what contortions were needed to implement this. Obviously now GHC
supports both anyway, so we've already paid whatever cost was
involved.

CApiFFI: maybe
The only reason this isn't a "yes" is that I don't know if this
impacts the build pipeline or performance of compilation at all. If it
only causes an impact when it actually gets used, I see no harm in
turning it on by default.

CPP: no
I like this extension, but it's better to have some indication that
it's in use on a per-file basis.

CUSKs: no
This is already legacy.

ConstrainedClassMethods: yes
As far as I can tell, this removes a restriction that served no
purpose to begin with.

ConstraintKinds: yes
You need to import the Constraint kind to use it anyway. Might as well
make it work when you do.

DataKinds: no
I don't want this lifting happening automatically everywhere prior to
having Dependent Haskell really figured out. This also worsens various
error messages for beginners as well. I think it's fair enough to turn
it on when you really want it -- I'd actually prefer it was on a
per-declaration basis myself.

DatatypeContexts: no
The context this enables is pointless and doesn't do what anyone would
reasonably expect the first time they saw it.

DefaultSignatures: yes
This harms very little and enables some very good idioms when it comes
to classes of monads specifically (i.e. you can provide defaults which
lift through a transformer in the case that the monad is a transformer
application, and never have to fill in instances manually apart from
the one transformer that implements the features properly.)

DeriveAnyClass: no
This is dangerous to have on by default. I would support it being
available by default when using the DerivingStrategies syntax though.

DeriveDataTypeable: yes
The name of this extension is no longer appropriate, as Typeable no
longer needs to be derived. Still, if I derive Data, I'd like that to
just work without having to tell GHC that yes, I really do mean it.

DeriveFoldable: yes
DeriveFunctor: yes
DeriveGeneric: yes
DeriveTraversable: yes
Similar to the above.

DeriveLift: maybe
I think this should be enabled by TemplateHaskell, but I don't think
TemplateHaskell should be default on.

DerivingStrategies: yes
I don't use this enough as it is, since it's usually not worth writing
out an additional LANGUAGE pragma for, but it's really good for
clarity about where the instances are coming from.

DerivingVia: yes
This is also excellent and seems harmless to turn on by default.

DisambiguateRecordFields: no
DuplicateRecordFields: no
I consider these actively harmful and I wish they'd go away.

EmptyCase: yes
EmptyDataDecls: yes
EmptyDataDeriving: yes
These are pretty meh, but I don't see much reason to have GHC complain
about empty types and make people flip the switch.

ExistentialQuantification: yes
Syntactically distinguished and sometimes quite useful. Not sure if we
need the non-GADT syntax, but there's little harm in it.

ExplicitForAll: yes
I mean, I'm going to vote yes on GADTs, so...

ExplicitNamespaces: maybe
I'd want this turned on if TypeOperators ends up turned on, but I'm
voting no on TypeOperators.

ExtendedDefaultRules: no
This extension is only for GHCi imo.

FlexibleContexts: yes
Having to turn this on is obnoxious, and perhaps one of the reasons we
want to define GHC2021 in the first place.

FlexibleInstances: yes
Similarly to FlexibleContexts, but very slightly more controversial
perhaps. The only arguments against this I'm aware of have to do with
issues surrounding functional dependencies that should be solved
separately (and blamed on functional dependencies in the first place).

ForeignFunctionInterface: no
I wouldn't be against turning this on by default, but also the need
for doing so is rare, and I'm uncertain about whether flipping this
switch induces overhead in the build. I also see no harm in making
users turn it on explicitly.

FunctionalDependencies: yes
Oof, this would have been a solid "yes" from me at any point before
last week, but now I'm really fighting with myself on this one. I
think we can fix the issues with fundeps, but there are some really
fun issues right now. Still, I think they're a vital enough part of
how programming gets done in modern Haskell, and it's easy enough to
tell when they're being used.

GADTSyntax: yes
GADTs: yes
GADTs are just inside where I draw the line on fancy types right now.
I just keep discovering new practical applications for them (they're
really good for encoding the types of responses to APIs, for
instance). The syntax is also distinct enough that toggling it on
isn't going to cause confusion.

GHCForeignImportPrim: maybe
I don't know what this is.

GeneralisedNewtypeDeriving: yes
My argument for this one is just that it's so often desirable. All the
stuff with roles we needed in order to make it not possible to break
things with it is still a little rough, but this is a key component of
being able to lean on the type system and get things done without
wasting massive amounts of time.

HexFloatLiterals: yes
Sure, why not? Seems a natural extension of the syntax for hexadecimal
literals to allow this, and I can imagine numerical algorithms people
wanting it.

ImplicitParams: no
I don't outright *hate* ImplicitParams, but I don't love the extension
either, and I want the fair warning when people turn this on.

ImportQualifiedPost: yes
This is a bit controversial in my own head, but while I'd never turn
this extension on manually or actually suggest that people implement
it, I do really think that "import Foo qualified" reads a whole lot
better and would be handled by tools better (easier to sort imports!).
It's sort of the way that the syntax always should have been, so maybe
let's turn it on and move in that direction!

ImpredicativeTypes: no
This might have been fixed in modern GHC with the new developments,
but I don't have enough evidence that it's safe to turn this on. It's
been in a state of brokenness on and off for so long that I'd hesitate
to encourage people to use it. Maybe in GHC2026 or something.

IncoherentInstances: no
Obviously not.

InstanceSigs: yes
Can be really good for readability. If this didn't exist, I'd often be
writing those signatures as comments anyway, and it's good to have the
compiler check them and make sure that my impression of the type is
correct.

InterruptibleFFI: maybe
I do kind of feel that FFI ought to just turn this one on by itself,
but I'm not sure about the implications of toggling FFI on everywhere.

KindSignatures: yes
I don't see any harm in this being on.

LambdaCase: yes
I rather like LambdaCase and use it a fair amount myself, but I'm also
not sure it's definitely the ideal syntax in the long run? Still, I
use it enough that having this on by default is better than not for
now.

LexicalNegation: no
While the name is suggestive of what this is, it's not currently
documented in the latest GHC User's Guide. Also, I'm not a huge fan of
fiddling with how negation works -- it's ugly, but let it be one kind
of ugly rather than several kinds of ugly.

LiberalTypeSynonyms: yes
This just corrects a mistake in the specification, as far as I'm concerned.

LinearTypes: no
sigh.

MagicHash: no
The purpose of this extension is to be explicitly and manually enabled
to provide access to internals. It shouldn't even be up for voting.

MonadComprehensions: no
It kind of pains me to say no here. If it was just the simple version
without the weird grouping shenanigans, I would be voting yes, since
there's not a whole lot of reason to make the syntax only work with
lists. TransformListComp is kind of baroque and confusing though, and
it's currently implied by this.

MonadFailDesugaring: yes
At least, until we get rid of this temporary extension altogether,
this is already default.

MonoLocalBinds: yes
I *really* wish this were not required to make TypeFamilies and GADTs
work, but it is.

MultiParamTypeClasses: yes
These have been a staple forever now.

MultiWayIf: maybe
This should probably be handled however we end up handling LambdaCase.
I occasionally use it, but less than LambdaCase. It's probably fine if
it remains a manually-toggled extension.

NPlusKPatterns: no
Having these off has been the status quo for a long time. While
there'll always be a place in my heart for c*n+k patterns, it's easy
to understand why this should not be turned on.

NamedFieldPuns: no
Better than RecordWildCards, but still awkward to shadow like that,
and I still want fair warning of usage.

NamedWildCards: yes
This makes tools like ghcid more useful, even though it shouldn't
significantly impact final programs.

NegativeLiterals: maybe
More fussing about the lexical syntax of negation. I'm not sure about
this one. It's probably fine.

NoImplicitPrelude: no
Haha.

NoMonomorphismRestriction: yes
I've never once had the MR make my life easier or better, but I have
wasted at least a few hours over the past couple decades in
frustration due to something that it quietly decided should be
monomorphic.

NoPatternGuards: no
Weird double negative here. Pattern guards are good and should stay on.

NoTraditionalRecordSyntax: no
Too disruptive to disable this, and while I can imagine better uses
for the syntax it occupies, traditional record syntax isn't really
that bad.

NondecreasingIndentation: no
As far as I'm concerned, it was a mistake for Haskell2010 to change
this, let's revert the mistake. Helping people indent their code in a
less clear way is bad. Having a nested do-block indented to the same
place as the enclosing one is *extremely* frustrating to encounter
when reading unfamiliar code.

NullaryTypeClasses: no
As much of a fan I usually am of handling the zero case, this one
really is pretty awkward, and I don't think it's all that bad to
require the pragma to turn it on first.

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

NumericUnderscores: yes
I can see why someone might want them, but they also look pretty
awkward. I've never used them, but this also seems harmless.

OverlappingInstances: no
Overlapping instances are bad in essentially any case that doesn't
involve hiding the class, and when you use them, you're probably
better off with the per-instance pragmas anyway.

OverloadedLabels: no
Oof, all the stuff that has cropped up surrounding record syntax is so
painful. None of it should default to on at the very least.

OverloadedLists: no
This extension is probably fine, but it's rare enough that I'd like
the extra warning that list literals are not literally lists.

OverloadedStrings: yes
Kind of essential. We use Data.Text everywhere in our applications,
and this is basically mandatory for that. Feels kind of funny to vote
differently between this and OverloadedLists, but there you go.

PackageImports: maybe
Don't hate this, but also don't use it enough to care.

ParallelListComp: no
Kind of strange and very uncommon.

PartialTypeSignatures: no
I like using holes in types sometimes, but I *usually* don't want to
leave those holes in my code. In the cases where I might want to,
having to flip the switch seems okay.

PatternSynonyms: no
This extension has a bunch of rough edges still, and I'm still
hesitant to encourage its use until those get hammered out.

PolyKinds: yes
Having this turned off can result in extremely confusing errors when
poly-kinded terms are imported and used.

PostfixOperators: no
Nobody uses this, it's basically frivolous.

QualifiedDo: no
This is too new to turn on by default. Maybe part of GHC2026.

QuantifiedConstraints: yes
This has been around for a few versions and has been very successful in my view.

QuasiQuotes: no
TH probably shouldn't be on by default.

RankNTypes: yes
You might not need these every day, but I think there's no harm in
having the compiler accept these types when the programmer writes
them.

RebindableSyntax: no
Knowing when this is in use explicitly is helpful, since it could
otherwise be quite startling, or even help sneak malicious code into
something.

RecordWildCards: no
Although there are some rather nice idioms that this makes possible,
generally things which bind variables without mentioning them and
things which force you to shadow variables are not great.

RecursiveDo: yes
Could we just have rec without mdo perhaps?

RoleAnnotations: no
I'm not yet convinced that roles are the right solution to the problem
that they solve.

Safe: no
This is a user flag. Should not be in this list.

ScopedTypeVariables: yes
Right now, this is almost mandatory. There are details about how it
works that I think should perhaps not stay the way they are forever,
but it's too inconvenient to have this off.

StandaloneDeriving: yes
This is fairly common and good. Maybe deriving should always have been
standalone.

StandaloneKindSignatures: yes
This seems uncontroversial so long as TypeFamilies ends up being on as well.

StarIsType: yes
Too much code needs this still, and it doesn't require extra imports
to use, so in practice, it's still quite convenient.

StaticPointers: no
Too obscure, and the only time I've seen this used in one of our
projects, it ended up seeming like a bit of a mistake to have done so
(not to say that it doesn't have legitimate uses as well, just that
they're pretty rare).

Strict: no
If this becomes default, I quit.

StrictData: no
Better to be explicit.

TemplateHaskell: no
TemplateHaskellQuotes: no
I don't really think TH should be on by default. It would be worth
figuring out if it has any impact on compilation time when switched on
and unused though.

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

Trustworthy: no
This is meant to be explicit. Shouldn't be up for debate.

TupleSections: yes
I usually don't use this, but I might on occasion if it were turned on
by default, and it seems a natural thing to expect from the language.

TypeApplications: yes
This one I'm less sure about than many of the other
type-system-related ones, as those mostly don't steal syntax. This
doesn't steal *too* much syntax though, and when you need it, it's
quite handy. I don't like the way that TypeApplications works even
when types were not explicitly quantified, but that ship has basically
sailed.

TypeFamilies: yes
This is one of those "might not be around forever" extensions that
still occupies an important enough place in modern-day Haskell that I
think it should get turned on by default for now.

TypeFamilyDependencies: no
This extension of type families has only seen quite rare use thus far,
and it doesn't feel entirely complete.

TypeInType: yes
This makes things work better across the board, at least for now.
There's an obvious downside to it, but until we're really going to
start caring about termination, it's not a huge deal.

TypeOperators: no
I wish this could be turned on only for :~: -- perhaps it's worth
turning on just for the sake of that type, but otherwise, I prefer to
encourage people to write their type constructors prefix, for the most
part. I'm not sure about this one.

TypeSynonymInstances: yes
Doesn't seem like there's any harm in unfolding type synonyms before
checking if the instance is otherwise valid.

UnboxedSums: maybe
UnboxedTuples: maybe
I don't really have a strong feeling one way or the other about
whether these are on or off by default. On the one hand, it seems fine
to enable the syntax, on the other, it has a bit of the same feeling
as auto-enabling MagicHash (though less so). Usually when you get to
this point, you're fine-tuning code, and flipping a manual switch is
no problem.

UndecidableInstances: no
I'm tempted to say yes on this, but there are some cases right now
where instead of actually not terminating in the face of undecidable
instances, GHC will come to a loopy conclusion in finite time. Maybe
sometimes that's essential (I seem to recall a case involving scrap
your bopilerplate), but it also means we end up with a way to subvert
any functional dependency, for example:

class C a b | a -> b where ...
instance (C Int b) => C Int b where ...

There are also cases where you didn't mean for an instance to be
undecidable, and this catches you, so perhaps it's good to leave it
off by default.

UndecidableSuperClasses: maybe
I have less explicit reason to disallow this than
UndecidableInstances, though it does feel weird to come to a different
conclusion on it, and there may be downsides that I'm unaware of. I'll
leave this as maybe.

UnicodeSyntax: no
I like being able to type all my identifiers without special editor support.

UnliftedFFITypes: maybe
If FFI is turned on by default, then this should be, but I'm not sure
FFI has any place being turned on by default.

UnliftedNewtypes: no
This seems kind of new to enable by default. Seems natural enough that
if someone writes an unlifted newtype to just accept their declaration
though. Also, all stuff involving syntax with "#" in it I think is
fine to leave as a flag.

Unsafe: no
This is explicitly a flag and we shouldn't even be voting on it.

ViewPatterns: no
The results of using this are usually hard to read. Sometimes in
conjunction with PatternSynonyms it can be used to build nice syntax,
but it can be turned on explicitly in those moments, I think.

On Tue, 24 Nov 2020 at 04:34, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Dear Committee,
>
> the requested data (hackage and survey) is in, has been aggregated,
> cooked, seasoned and is ready for consumption. 116 extensions are
> waiting on your assessment, so time to vote!
>
> ## Procedure
>
> Please vote by email to this list, in a response to this thread.
>
> I want to make tallying easy and automatic, and my code will consider
> an extension Foo voted for if you write "Foo: yes" on its own line.
> This means you can include rationales, write "Foo: maybe" and "Foo: no"
> to remind yourself and others that about where you are, and you can
> safely quote other’s mails. For example, if you write:
>
> ---- begin
> example ----
>
> Easy ones:
>
> DeriveFooBar: yes
> OverloadedBen: no
>
> These ones are tricky:
>
> ImplicitExceptions: yes
>   I know nobody likes that one, but I do.
>
> RandomEvaluationOrder: maybe
>   Not sure about this one, here is why…
>
>
> > Richard wrote:
> > DependentHaskell: yes
> > Rationale: See my thesis
>
> I’m not convinced yet, tell me more, so
> DependentHaskell: maybe
>
> ---- end example ----
>
> then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes”
> matters, “no”, “maybe” and “later” are all ignored.
>
> I will shortly send my first ballot around. Also see the end of this
> mail for a copy’n’paste template.
>
> You can update your vote as often as you want. Please always send your
> full votes (I will only consider your latest email). I encourage you to
> do that early, e.g. maybe start with a mail where you list the obvious
> yes and nos, and keep some at maybe and then refine.
>
> The timeline says first votes should be in within two weeks, and then a
> bit more to refine. But the earlier the merrier!
>
> The quota is 8. In particular, if everyone votes (and I hope everyone
> will), an extension won’t make it this round if 4 don’t include it.
>
> ## Data
>
> Please see
> https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data
> for the data, including explanations. It is intentionally not sorted by
> the data, as the choice of ranking function would already be quite
> influencing.
>
> You may want to play around with that data, e.g. sort it by your own
> criteria etc. I looked long for an online service where I can upload
> the data and allow you to explore it, but then I noticed that that's a
> bit stupid, since we all probably can do it best with Haskell.
>
> So I made it easy to load the data into GHCi, see the instructions at
> https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md
> which allow you, for example, to do this
>
> *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts)
> AllowAmbiguousTypes: 195
> CPP: 192
> IncoherentInstances: 176
> Arrows: 156
> Strict: 153
> ImplicitParams: 147
> UndecidableInstances: 144
> OverlappingInstances: 144
> Unsafe: 139
> TemplateHaskell: 137
>
> Of course, if someone wants to upload the data somewhere and share
> that, that's also useful.
>
>
> Let me know if some of this doesn't quite work for you, and should be
> improved. Maybe we need a web form instead of mails?
>
>
> ## PS: Blank ballot
>
> To start, you could copy the following into an email
>
> AllowAmbiguousTypes: maybe
> ApplicativeDo: maybe
> Arrows: maybe
> BangPatterns: maybe
> BinaryLiterals: maybe
> BlockArguments: maybe
> CApiFFI: maybe
> CPP: maybe
> CUSKs: maybe
> ConstrainedClassMethods: maybe
> ConstraintKinds: maybe
> DataKinds: maybe
> DatatypeContexts: maybe
> DefaultSignatures: maybe
> DeriveAnyClass: maybe
> DeriveDataTypeable: maybe
> DeriveFoldable: maybe
> DeriveFunctor: maybe
> DeriveGeneric: maybe
> DeriveLift: maybe
> DeriveTraversable: maybe
> DerivingStrategies: maybe
> DerivingVia: maybe
> DisambiguateRecordFields: maybe
> DuplicateRecordFields: maybe
> EmptyCase: maybe
> EmptyDataDecls: maybe
> EmptyDataDeriving: maybe
> ExistentialQuantification: maybe
> ExplicitForAll: maybe
> ExplicitNamespaces: maybe
> ExtendedDefaultRules: maybe
> FlexibleContexts: maybe
> FlexibleInstances: maybe
> ForeignFunctionInterface: maybe
> FunctionalDependencies: maybe
> GADTSyntax: maybe
> GADTs: maybe
> GHCForeignImportPrim: maybe
> GeneralisedNewtypeDeriving: maybe
> HexFloatLiterals: maybe
> ImplicitParams: maybe
> ImportQualifiedPost: maybe
> ImpredicativeTypes: maybe
> IncoherentInstances: maybe
> InstanceSigs: maybe
> InterruptibleFFI: maybe
> KindSignatures: maybe
> LambdaCase: maybe
> LexicalNegation: maybe
> LiberalTypeSynonyms: maybe
> LinearTypes: maybe
> MagicHash: maybe
> MonadComprehensions: maybe
> MonadFailDesugaring: maybe
> MonoLocalBinds: maybe
> MultiParamTypeClasses: maybe
> MultiWayIf: maybe
> NPlusKPatterns: maybe
> NamedFieldPuns: maybe
> NamedWildCards: maybe
> NegativeLiterals: maybe
> NoImplicitPrelude: maybe
> NoMonomorphismRestriction: maybe
> NoPatternGuards: maybe
> NoTraditionalRecordSyntax: maybe
> NondecreasingIndentation: maybe
> NullaryTypeClasses: maybe
> NumDecimals: maybe
> NumericUnderscores: maybe
> OverlappingInstances: maybe
> OverloadedLabels: maybe
> OverloadedLists: maybe
> OverloadedStrings: maybe
> PackageImports: maybe
> ParallelListComp: maybe
> PartialTypeSignatures: maybe
> PatternSynonyms: maybe
> PolyKinds: maybe
> PostfixOperators: maybe
> QualifiedDo: maybe
> QuantifiedConstraints: maybe
> QuasiQuotes: maybe
> RankNTypes: maybe
> RebindableSyntax: maybe
> RecordWildCards: maybe
> RecursiveDo: maybe
> RoleAnnotations: maybe
> Safe: maybe
> ScopedTypeVariables: maybe
> StandaloneDeriving: maybe
> StandaloneKindSignatures: maybe
> StarIsType: maybe
> StaticPointers: maybe
> Strict: maybe
> StrictData: maybe
> TemplateHaskell: maybe
> TemplateHaskellQuotes: maybe
> TransformListComp: maybe
> Trustworthy: maybe
> TupleSections: maybe
> TypeApplications: maybe
> TypeFamilies: maybe
> TypeFamilyDependencies: maybe
> TypeInType: maybe
> TypeOperators: maybe
> TypeSynonymInstances: maybe
> UnboxedSums: maybe
> UnboxedTuples: maybe
> UndecidableInstances: maybe
> UndecidableSuperClasses: maybe
> UnicodeSyntax: maybe
> UnliftedFFITypes: maybe
> UnliftedNewtypes: maybe
> Unsafe: maybe
> ViewPatterns: maybe
>
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From mail at joachim-breitner.de  Mon Dec 14 21:41:38 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Dec 2020 22:41:38 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Voting starts
In-Reply-To: <CAF3RzK-nG8W6J6hC-kv4S_vV95kArnqmihEYCBFPyCV8vOUdYA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <CAF3RzK-nG8W6J6hC-kv4S_vV95kArnqmihEYCBFPyCV8vOUdYA@mail.gmail.com>
Message-ID: <89e204386f31e5aa7115d77f7f2eef83b6580894.camel@joachim-breitner.de>

Hi,

thanks! I’ve updated 
https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst
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.html#extension-NumDecimals

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



From mail at joachim-breitner.de  Mon Dec 14 22:22:42 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Dec 2020 23:22:42 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>

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-ghc2021.rst#data
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?path=43548.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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Mon Dec 14 22:43:19 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Dec 2020 23:43:19 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Vote update
In-Reply-To: <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de>
 <ba095c4f181af820444caf2bfb27e25309f65985.camel@joachim-breitner.de>
Message-ID: <c9b239a89e7b0c2b57de62811746eaeaf0981179.camel@joachim-breitner.de>

Another update:


NegativeLiterals: no
  -- ^ The latest docs paint an incomplete picture of this, and make it look
  like it only affects desugaring of “negate followed by literal”. But it does
  more, affects parsing, changes `x-1`, and changes meaning in 9.0.
  So (unfortunately), no. Thanks Iavor for pointing that out on kiala.com

MonoLocalBinds: no
TypeFamilies: no
  -- ^ Not uncontentious, as per Richard’s plea

PolyKinds: yes
  -- ^ Got convinced by Richard


============================================================================

Unchanged votes follow:

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

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

Controversial and/or pleaded against:

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

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).


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


I’d also like 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 (Alejandro, Arnaud, Iavor and SPJ) might be swayed by that clarification.


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:

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

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



From simonpj at microsoft.com  Tue Dec 15 12:13:13 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2020 12:13:13 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update
	/	kialo.com
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0222A119E82B8250A4B2D287ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing

You all have edit rights.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 22:23
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7
|  09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3i5Pfxw2%2B
|  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10
|  d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I8nLXqK
|  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1
|  dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7N%2FDBw%2BRwVr
|  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452
|  5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
|  13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=byGDRSmjPqFiUAGe5fjF
|  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0

From simonpj at microsoft.com  Tue Dec 15 12:18:20 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2020 12:18:20 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update
	/	kialo.com
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Writing down the summary here
https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing

allows me to ask:

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

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 22:23
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7
|  09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3i5Pfxw2%2B
|  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10
|  d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I8nLXqK
|  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1
|  dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7N%2FDBw%2BRwVr
|  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452
|  5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
|  13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=byGDRSmjPqFiUAGe5fjF
|  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0

From simonpj at microsoft.com  Tue Dec 15 12:25:07 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2020 12:25:07 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update
	/	kialo.com
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02221244BC949191C7F4466DADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 22:23
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7
|  09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3i5Pfxw2%2B
|  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10
|  d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I8nLXqK
|  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1
|  dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7N%2FDBw%2BRwVr
|  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452
|  5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
|  13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=byGDRSmjPqFiUAGe5fjF
|  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0

From trupill at gmail.com  Tue Dec 15 12:48:12 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 15 Dec 2020 12:48:12 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>

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

> Writing down the summary here
>
> https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing
>
> 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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 14 December 2020 22:23
> |  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7
> |  09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> |  7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> |  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3i5Pfxw2%2B
> |  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10
> |  d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I8nLXqK
> |  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de
> |
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  oachim-
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1
> |  dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> |  7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7N%2FDBw%2BRwVr
> |  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
> |
> |
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452
> |  5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
> |  13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=byGDRSmjPqFiUAGe5fjF
> |  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/3408b587/attachment.html>

From mail at joachim-breitner.de  Tue Dec 15 12:50:48 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 15 Dec 2020 13:50:48 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
 kialo.com
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <3683915a6d8b9eabc96068d98cd8ff903cedc4f4.camel@joachim-breitner.de>

Hi,

Am Montag, den 14.12.2020, 23:22 +0100 schrieb Joachim Breitner:
> 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?path=43548.0

btw, the first time you post or comment, your change will be held for
moderation. Once I approve it, you can post or comment freely. Sorry
for that friction.

Not sure how useful that format is, but I have learned a few things
about some extension that I didn’t know before already (in particular
that NegativeLiterals is far less harmless than it sounds. I removed my
vote and it is no longer only barely out.)

But maybe SPJ’s google doc is better suited to shape the discussion?

Cheers,
Joachim

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



From simonpj at microsoft.com  Tue Dec 15 13:00:20 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2020 13:00:20 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
 kialo.com
In-Reply-To: <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
Message-ID: <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>

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

Simon

From: Alejandro Serrano Mena <trupill at gmail.com>
Sent: 15 December 2020 12:48
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee at 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 at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
Writing down the summary here
https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing<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 <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
|  Sent: 14 December 2020 22:23
|  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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&amp;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&amp;sdata=3i5Pfxw2%2B
|  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;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&amp;sdata=I8nLXqK
|  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de<mailto:mail at 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&amp;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&amp;sdata=7N%2FDBw%2BRwVr
|  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
|
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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&amp;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&amp;sdata=byGDRSmjPqFiUAGe5fjF
|  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/56f5603f/attachment-0001.html>

From trupill at gmail.com  Tue Dec 15 20:06:51 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 15 Dec 2020 20:06:51 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOtp1m7hNvnEELryJz9G+JFg4CxXfz0ERJYurvvFPdJJcg@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
 <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>
 <CAHnFXOtp1m7hNvnEELryJz9G+JFg4CxXfz0ERJYurvvFPdJJcg@mail.gmail.com>
Message-ID: <CAHnFXOuhjY_kXK89wZhoOavTMTNMFH6azyXAMcF95MhkCGpsmA@mail.gmail.com>

 It seems that everything is solve now. Are the any further objections?
Otherwise I guess in a couple of days we can mark this as accepted.

Regards,
Alejandro

On 11 Dec 2020 at 22:39:39, Alejandro Serrano Mena <trupill at gmail.com>
wrote:

>
>
> On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Sorry -- I've lost track here a bit. What's the issue with the grammar?
>>
>
> In this comment
> https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-741785189
> :
>
> Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
>> modifiers but not two. Or do I misunderstand the braces? Spell it out please
>>
>
> Regards,
> Alejandro
>
>
>> I'm quite happy to label this experimental. The key aspect of the
>> proposal is just to outline a way forward with adding syntax.
>>
>> Richard
>>
>> On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Should we mark them as “accepted” with the following text?
>>
>> The Committee accepts this proposal as experimental. This means that the
>>> Committee expects changes to this feature in the future, maybe as the
>>> result of other accepted proposals.
>>>
>>
>> If you agree, then we can accept this proposal once a little remaining
>> issue with the grammar has been clarified.
>>
>> Regards,
>> Alejandro
>>
>>
>> On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>>> That was the point of my previous email: accept, and
>>> accept-as-experimental are actually one and the same.
>>>
>>> Objectively, yes.  But I think it helps users to advertise a feature as
>>> experimental.  It’s a signal to users that this feature is, well,
>>> experimental.  It is more likely to change.
>>>
>>> It’s only an indication not a clear distinction.  But I find it helpful.
>>>
>>> For me, it also reflects how I evaluate the proposal.  For a change to a
>>> well-established feature, we have a lot of experience in how people use
>>> that feature.
>>>
>>> For experimental features we don’t.  Example: defaulting for
>>> matchability for unsaturated type families.  We don’t have unsaturated type
>>> families right now, so we don’t have any code that uses them, and hence
>>> zero in-the-wild experience about matchability defaulting.  We shouldn’t
>>> spend ages arguing the toss – just trust Csongor’s judgement and give it a
>>> try, but advertising that details may change.
>>>
>>> Simon
>>>
>>>
>>> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> *Sent:* 10 December 2020 08:06
>>> *To:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Cc:* Richard Eisenberg <rae at richarde.dev>;
>>> ghc-steering-committee at haskell.org; Simon Peyton Jones <
>>> simonpj at microsoft.com>
>>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>>> Recommendation: Acceptance
>>>
>>>
>>> That was the point of my previous email: accept, and
>>> accept-as-experimental are actually one and the same.
>>>
>>>
>>> What Simon is driving at, I think, is: depending on what the proposal is
>>> about, we want to apply more or less strict standard of acceptance (if a
>>> proposal is about fixing something in an existing feature, then we better
>>> be rather sure that it is indeed an improvement; but if it's about adding
>>> something new in an untrodden territory, then we can't really be sure, and
>>> it's worth experimenting with).
>>>
>>>
>>> On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>> Dear all,
>>>
>>> As the shepherd of this proposal, I’m quite confused about what the
>>> outcome should be. The ghc-proposals README states that:
>>>
>>>
>>> Acceptance of the proposal implies that the implementation will be
>>> accepted into GHC provided it is well-engineered, well-documented, and does
>>> not complicate the code-base too much.
>>>
>>>
>>>
>>> Most of the Committee seems to lean towards “this seems OK right now,
>>> but we don’t want to be locked” or “mark this as experimental”. However,
>>> there’s no such notion as “accept as experimental”. Furthermore, as it
>>> stands the proposal gives some syntax, and then asks any new extensions to
>>> use that syntax; so it cannot be completely thought as a feature by itself.
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> It's always possible to change. I don't think accepting a proposal means
>>> (or ought to mean) that we are locked into anything. Accepting a proposal
>>> means that we won't oppose a design-related argument to a PR that
>>> implements (part or all of) an accepted proposal.
>>>
>>>
>>> I don't know how to quantify the degree of confidence that we have in
>>> the stability of a proposal. Here we are all saying: this is better than
>>> anything so far, and we rather need something like this to be a thing, but
>>> it's really a shot in the dark. And this lack of confidence will be
>>> reflected in the manual description. But even if we are confident in the
>>> stability of a proposal, it may very well happen that it changes
>>> dramatically, even soon.
>>>
>>>
>>> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>
>>> I’ve replied on GitHub.  Generally in favour.  But mark it as
>>> experimental… I don’t want to be locked into “we decided on this in Dec
>>> 2020 so now it’s too late”.  WE can learn from experience.
>>>
>>>
>>> Simon
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>> Serrano Mena
>>> *Sent:* 03 December 2020 20:17
>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>>> Recommendation: Acceptance
>>>
>>>
>>> Dear Committee,
>>>
>>>
>>> Richard has requested for us to consider the new version of this
>>> proposal. As opposed to the previous version, this one is only about
>>> reserving syntax for “modifiers”, which at the beginning would be used for
>>> things like linearity or matchability of arrows.
>>>
>>>
>>> I think this is a good proposal, and one which would save us from
>>> re-considering syntax for every possible extension (and if linearity
>>> appears before the arrow and matchability after it, where would a future
>>> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>> To my surprise, I found myself leaning against. So I updated and
>>> simplified the proposal to remove Modifier. This makes modifiers a bit more
>>> magical, but more likely to actually work in practice. The type inference
>>> story previously may have been intractable.
>>>
>>>
>>> I've requested that the committee consider the updates in parallel with
>>> community feedback.
>>>
>>>
>>> Thanks,
>>>
>>> Richard
>>>
>>>
>>> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>>
>>> After some discussion in the GitHub thread, changes are going to arrive
>>> to the proposal. I think the best is to send the proposal back to the
>>> “Needs revision” state.
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>>>
>>> I left a few comments and questions on the PR itself, but I'm leaning
>>> towards rejecting the proposal in its current form as well. This doesn't
>>> (yet) feel like a generic mechanism, in particular because the only
>>> modifier that has been specified would be deeply wired into GHC itself.
>>>
>>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>>
>>> Mena:
>>>
>>> > Dear all,
>>>
>>> > This proposal suggests adding syntax for a general notion of
>>>
>>> > modifiers, like the ones we’ve been talking about lately affecting
>>>
>>> > linearity or matchability of arrows. For example, if linear types and
>>>
>>> > unsaturated families are accepted as they stand, we would have `Int
>>>
>>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>>
>>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>>
>>> >
>>>
>>> > Since the amount of modifiers is likely to increase in the future, I
>>>
>>> > think it’s a great idea to agree and reserve such syntax, instead of
>>>
>>> > coming up with different ways on each proposal. I thus recommend
>>>
>>> > acceptance of this proposal.
>>>
>>> >
>>>
>>> > The proposal itself:
>>>
>>> > (1) introduces syntax for modifiers in types and defines how to
>>>
>>> > type/kind check them,
>>>
>>> > (2) reserved such syntax for other uses in declarations and terms.
>>>
>>> >
>>>
>>> > I think the proposal still has its merits only with (1), even though
>>>
>>> > I lean towards accepting both parts of it.
>>>
>>>
>>>
>>> I like the idea of reserving syntax here, but parts of the proposal
>>>
>>> smell a bit like premature generalization to me. Are we confident that
>>>
>>> all annotations we eventually would like to use with this feature can
>>>
>>> be expressed as types of a kind that is an instance of Modifier? Or
>>>
>>> should we reserve the ability to have annotations that don't fit that
>>>
>>> model?
>>>
>>>
>>>
>>> Would we ever have annotation that may affect phases earlier than than
>>>
>>> typechecking? What if we want to use (%type e) and (%data e) to help
>>>
>>> with the SingleNamepace issues? Look like useful annotations to me, but
>>>
>>> I am not sure if they fit the framework proposed here.
>>>
>>>
>>>
>>> The fact that we special-case %1 supports that.
>>>
>>>
>>>
>>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>>
>>> isn't that indication that using the type system to model the various
>>>
>>> modifiers might be the wrong tool?
>>>
>>>
>>>
>>> I wonder if there is a way where the %(…) on it’s own only reserve
>>>
>>> syntax, and the various uses of that syntax can be disambiguated
>>>
>>> _statically_ based on the content of ….
>>>
>>>
>>>
>>> Not great syntax, because not concise, enough, but morally I’d feel
>>>
>>> more at ease with
>>>
>>>
>>>
>>>   Int %(multiplicity Many) -> Int
>>>
>>>   Int %(multiplicity 1) -> Int
>>>
>>>   Int %(multiplicity m) -> Int
>>>
>>>
>>>
>>> where multiplicity is a modifier keyword, to express the existing
>>>
>>> features (including implicit generalization of m). Then we can extend
>>>
>>> this to
>>>
>>>
>>>
>>>   Int %oneShot -> Int
>>>
>>>
>>>
>>> and
>>>
>>>
>>>
>>>   Int %(matchability M) -> Int
>>>
>>>
>>>
>>> and maybe even
>>>
>>>
>>>
>>>   foo (%type [a]) -- where foo :: forall a -> ()
>>>
>>>
>>>
>>> which is a modifier that
>>>
>>>
>>>
>>>
>>>
>>> So at the moment, I am inclined to reject this proposal, until I am
>>>
>>> convinced that we are not painting ourselves into a “all modifiers are
>>>
>>> types of special kinds and that’s all the syntax and behaviour we ever
>>>
>>> need” corner.
>>>
>>>
>>>
>>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>>
>>> should we also be able to annotate other infix operators, i.e.
>>>
>>>
>>>
>>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>>
>>>   infixexp ::= lexp {modifier} qop infixexp
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Joachim
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Joachim Breitner
>>>
>>>   mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> ghc-steering-committee mailing list
>>>
>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/cbe21255/attachment-0001.html>

From marlowsd at gmail.com  Tue Dec 15 20:27:43 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 15 Dec 2020 20:27:43 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>

On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at 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 <trupill at gmail.com>
> *Sent:* 15 December 2020 12:48
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
> ghc-steering-committee at 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 at haskell.org> wrote:
>
> Writing down the summary here
>
> https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing
> <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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 14 December 2020 22:23
> |  To: ghc-steering-committee at 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&amp;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&amp;sdata=3i5Pfxw2%2B
> |  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;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&amp;sdata=I8nLXqK
> |  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at 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&amp;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&amp;sdata=7N%2FDBw%2BRwVr
> |  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
> |
> |
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at 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&amp;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&amp;sdata=byGDRSmjPqFiUAGe5fjF
> |  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/f8602f9e/attachment-0001.html>

From rae at richarde.dev  Tue Dec 15 21:21:56 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Dec 2020 21:21:56 +0000
Subject: [ghc-steering-committee] GHC2021 extensions should be sufficient
 for early intermediate Haskellers
Message-ID: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>

Hi all,

In thinking about how I feel about TypeFamilies (and why I lean against inclusion), I realized I had a new criterion:

* GHC2021 extensions should be sufficient for early-intermediate Haskellers

Today, users have to enable a number of extensions just to get basic work done (I'm looking at you, FlexibleContexts). So they learn just to take whatever suggestion is presented to them in an error message and apply it.

But if extensions were considered more exotic, then users might not be so willing to add an extension. They would have to consider whether they really want to opt into more challenging error messages and a wider horizon. TypeFamilies is an extension that significantly widens the horizon, but also invites new scary error messages. I think it should be opt in. But this gatekeeping works only if users will be thoughtful about enabling the extension; thus my new criterion.

What do we think about this?

(I thought of putting this on Kialo, but it didn't seem to fit the setup there. Maybe I've erred in not just blasting ahead.)

Richard

From rae at richarde.dev  Tue Dec 15 21:35:07 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Dec 2020 21:35:07 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
 kialo.com
In-Reply-To: <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
Message-ID: <010f017668540e62-16b839ce-c42d-4443-82a0-23ebadf7b5aa-000000@us-east-2.amazonses.com>



> On Dec 15, 2020, at 3:27 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> 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 :)

Yes. I think it's useful to be able to write blanks in types to get informative diagnostics from GHC. But I'm not yet convinced that we should encourage users to do this routinely (which is what enabling -XPartialTypeSignatures by default would mean). NamedWildCards increases the usefulness of writing blanks in types to get useful diagnostics by being able to name the blanks (great on its own) and express that two blanks should be the same.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/e65c6a96/attachment.html>

From rae at richarde.dev  Tue Dec 15 21:44:02 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 15 Dec 2020 21:44:02 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
 kialo.com
In-Reply-To: <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
Message-ID: <010f0176685c36cc-e3c598b6-65e8-43a8-97b8-e3f9bd448352-000000@us-east-2.amazonses.com>

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 <marlowsd at gmail.com> wrote:
> 
> On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <trupill at gmail.com <mailto:trupill at gmail.com>> 
> Sent: 15 December 2020 12:48
> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Cc: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> 
> Writing down the summary here
> https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing <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 <ghc-steering-committee-
> |  bounces at haskell.org <mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
> |  Sent: 14 December 2020 22:23
> |  To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;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&amp;sdata=3i5Pfxw2%2B
> |  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;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&amp;sdata=I8nLXqK
> |  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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 at joachim-breitner.de <mailto:mail at 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&amp;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&amp;sdata=7N%2FDBw%2BRwVr
> |  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;reserved=0
> |  
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;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&amp;sdata=byGDRSmjPqFiUAGe5fjF
> |  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/ce78bbe2/attachment-0001.html>

From mail at joachim-breitner.de  Wed Dec 16 08:20:39 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Dec 2020 09:20:39 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
 kialo.com
In-Reply-To: <010f0176685c36cc-e3c598b6-65e8-43a8-97b8-e3f9bd448352-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <010f0176685c36cc-e3c598b6-65e8-43a8-97b8-e3f9bd448352-000000@us-east-2.amazonses.com>
Message-ID: <0a75775e558e5af5c3c5717a75ee6b530d2c9696.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 15.12.2020, 21:44 +0000 schrieb Richard Eisenberg:
> 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.

I agree it’s odd that there is no comprehensive view of all claims.
Maybe because it’s designed for much larger discussions, where that
would be prohibitive.

Did you find the circular red/green icon in the top left? If you click
that you get some visualization of the whole thing.

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

It’s not very obvious, but a claim with no subclaims is simply a white
box, whereas a claim with subclaims is rendered as a white box with
another white box beneath it, slightly offset (like a stack of papers).

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

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

You can also comment on individual claims; maybe best if a claim is
incorrect or vague or needs to be clarified. That’s a form of debate.

Other than that, do we _need_ a debate? Or do we “just” need a good way
to collect and refine the pros and cons of each option, so that every
committee member can make a well-informed vote?

Note that we are not having a technical decision. There is no right or
wrong in including TupleSections in GHC2021. There are benefits and
downsides (and kialo might be better to collect them than a linear
medium like email), but in the end it’s all opinion based.

Cheers,
Joachim


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



From mail at joachim-breitner.de  Wed Dec 16 08:33:48 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Dec 2020 09:33:48 +0100
Subject: [ghc-steering-committee] GHC2021 extensions should be
 sufficient for early intermediate Haskellers
In-Reply-To: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>
References: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>
Message-ID: <772f0736f5466a6bb1a2ada3c606d9578a2857e4.camel@joachim-breitner.de>

Hi

Am Dienstag, den 15.12.2020, 21:21 +0000 schrieb Richard Eisenberg:
> * GHC2021 extensions should be sufficient for early-intermediate Haskellers

with sufficient, do you mean

   With GHC2021, early-intermediate Haskellers won’t have to enable any
   other extension.

That is an interesting proposal.

I worry that it is a hard criteria to evaluate, harder than “harmless
and uncontentious”, as everybody has different opinions about what an
intermediate Haskeller is, and to some it includes extensions that
others don’t think of as harmless or uncontentious.

In fact, doesn’t that mean to explicitly compromise on either the
harmless or the uncontentious criteria? (If it weren’t, we wouldn’t
need to propose a new criteria).


Maybe a bit related, but as we discuss refining criteria, I wonder if
we are implicitly applying the following criteria, and if we do, if we
really should:

   GHC2021 should be educative of best practices and good style.

(I worded it intentionally a bit tendentious). We have extensions that
are already perfectly guarded by their own syntax (e.g. UnicodeSyntax,
RecordWildCards), so by construction enabling the extension is harmless
– the only effect of not enabling the extension is to add friction for
those who want to use the extension, thus saying “yes, it’s there, but
we want to nudge you not to use them”.

Is that something we really want to do here?
(I find that sentiment a bit patronizing.)

There might be other arguments for exclusion, such as “readers need a
loud warning to watch out for uses of this feature” (which could maybe
applies to RecordWildCards, but probably not for UnicodeSyntax).

> (I thought of putting this on Kialo, but it didn't seem to fit the setup there. Maybe I've erred in not just blasting ahead.)

It would probably work well as a new top-level thesis, next to the
individual extensions, maybe worded as “Every extension needed by
intermediate Haskellers”

Cheers,
Joachim

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



From mail at joachim-breitner.de  Wed Dec 16 08:50:44 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Dec 2020 09:50:44 +0100
Subject: [ghc-steering-committee] #380 GHC2021: kialo.com: voting
In-Reply-To: <0a75775e558e5af5c3c5717a75ee6b530d2c9696.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <010f0176685c36cc-e3c598b6-65e8-43a8-97b8-e3f9bd448352-000000@us-east-2.amazonses.com>
 <0a75775e558e5af5c3c5717a75ee6b530d2c9696.camel@joachim-breitner.de>
Message-ID: <69e06725bb5f42b38a6b8fbc1fa24d1fbc1f4a5d.camel@joachim-breitner.de>

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



From arnaud.spiwack at tweag.io  Thu Dec 17 08:15:10 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Dec 2020 09:15:10 +0100
Subject: [ghc-steering-committee] GHC2021 extensions should be
 sufficient for early intermediate Haskellers
In-Reply-To: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>
References: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQmJXZh4C1k-2-PzqBpGdPbe0iRaTJCO7jBfj0qEZhCM5g@mail.gmail.com>

I don't agree with this sentiment at all, to be honest. In my opinion, the
ultimate fate of every extension is to be rolled into the standard or to be
relegated to the bins of history. The idea of having various levels of
languages based on how advanced they are perceived to be sounds
extraordinary to me (also quite a bit patronising).

Generally speaking, you opt in to a feature by using it. GHC2021 should not
have features that we, as a community, don't recommend using (the
bins-of-history ones); but, surely, TypeFamilies is not one of these. It is
not to say that GHC2021 should have TypeFamilies, but that them being
perceived as advanced is not, in my opinion, a relevant criterion. We
should be asking, instead, whether it is ready.

On Tue, Dec 15, 2020 at 10:22 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> In thinking about how I feel about TypeFamilies (and why I lean against
> inclusion), I realized I had a new criterion:
>
> * GHC2021 extensions should be sufficient for early-intermediate Haskellers
>
> Today, users have to enable a number of extensions just to get basic work
> done (I'm looking at you, FlexibleContexts). So they learn just to take
> whatever suggestion is presented to them in an error message and apply it.
>
> But if extensions were considered more exotic, then users might not be so
> willing to add an extension. They would have to consider whether they
> really want to opt into more challenging error messages and a wider
> horizon. TypeFamilies is an extension that significantly widens the
> horizon, but also invites new scary error messages. I think it should be
> opt in. But this gatekeeping works only if users will be thoughtful about
> enabling the extension; thus my new criterion.
>
> What do we think about this?
>
> (I thought of putting this on Kialo, but it didn't seem to fit the setup
> there. Maybe I've erred in not just blasting ahead.)
>
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/5c8b0055/attachment.html>

From arnaud.spiwack at tweag.io  Thu Dec 17 09:21:11 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Dec 2020 10:21:11 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
Message-ID: <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>

On Tue, Dec 15, 2020 at 9:28 PM Simon Marlow <marlowsd at gmail.com> 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. 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/13562e7e/attachment.html>

From marlowsd at gmail.com  Thu Dec 17 16:24:29 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Dec 2020 16:24:29 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>
Message-ID: <CANsrgP+7iF6r1yOC3mVsvX1eZMAjLGDYQcTs6p68XQ3jm3g8NQ@mail.gmail.com>

On Thu, 17 Dec 2020 at 09:21, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> On Tue, Dec 15, 2020 at 9:28 PM Simon Marlow <marlowsd at gmail.com> 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-warnings.html

(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/07aaa521/attachment.html>

From marlowsd at gmail.com  Thu Dec 17 16:34:38 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Dec 2020 16:34:38 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>

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 <mail at joachim-breitner.de>
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-ghc2021.rst#data
> 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?path=43548.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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/62d4176a/attachment.html>

From arnaud.spiwack at tweag.io  Thu Dec 17 16:42:06 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 17 Dec 2020 17:42:06 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <CANsrgP+7iF6r1yOC3mVsvX1eZMAjLGDYQcTs6p68XQ3jm3g8NQ@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>
 <CANsrgP+7iF6r1yOC3mVsvX1eZMAjLGDYQcTs6p68XQ3jm3g8NQ@mail.gmail.com>
Message-ID: <CAH6fHQnqE=+hcXMV0c35kaPMxA00gXdbAWT-5SCE477AXsoggQ@mail.gmail.com>

On Thu, Dec 17, 2020 at 5:24 PM Simon Marlow marlowsd at gmail.com
<http://mailto:marlowsd at 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

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 :: _ -> _
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/ddeec209/attachment-0001.html>

From marlowsd at gmail.com  Thu Dec 17 16:53:25 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Dec 2020 16:53:25 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <CAH6fHQnqE=+hcXMV0c35kaPMxA00gXdbAWT-5SCE477AXsoggQ@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>
 <CANsrgP+7iF6r1yOC3mVsvX1eZMAjLGDYQcTs6p68XQ3jm3g8NQ@mail.gmail.com>
 <CAH6fHQnqE=+hcXMV0c35kaPMxA00gXdbAWT-5SCE477AXsoggQ@mail.gmail.com>
Message-ID: <CANsrgPJe=TtZS9dHe8NtokbfR98ZZS=iw7+OP37KyRiPzx8pXQ@mail.gmail.com>

On Thu, 17 Dec 2020 at 16:42, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> On Thu, Dec 17, 2020 at 5:24 PM Simon Marlow marlowsd at gmail.com
> <http://mailto:marlowsd at 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 :: _ -> _
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/72691e18/attachment.html>

From iavor.diatchki at gmail.com  Thu Dec 17 17:19:25 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 17 Dec 2020 09:19:25 -0800
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
Message-ID: <CAGK9nuqN3B93MojfY7srtdVQ-XmgubmQ_DEfKEozbUhoMReyKg@mail.gmail.com>

I completely agree with Simon.  I voted against FFI in my first iteration,
because I forgot that we added in Haskell 2010 and I figured the FFI is
something that is not used all that often, so it doesn't hurt if you have
to mark when you use it.

When it was pointed out that it is already part of 2010 I updated my vote
to "yes" (I hope, it's a bit hard to see the votes).   I also think that
with FFI being enabled, there is absolutely no reason to not also turn on
CApiFFI, as it is very convenient when you do FFI stuff, and it only
affects FFI related things.

-Iavor




On Thu, Dec 17, 2020 at 8:40 AM Simon Marlow <marlowsd at gmail.com> 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 <mail at joachim-breitner.de>
> 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-ghc2021.rst#data
>> 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?path=43548.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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201217/aaff1a12/attachment.html>

From mail at joachim-breitner.de  Thu Dec 17 17:31:26 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Dec 2020 18:31:26 +0100
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CAGK9nuqN3B93MojfY7srtdVQ-XmgubmQ_DEfKEozbUhoMReyKg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAGK9nuqN3B93MojfY7srtdVQ-XmgubmQ_DEfKEozbUhoMReyKg@mail.gmail.com>
Message-ID: <653c4a724e47a1e46fff609a6953889566b50cf2.camel@joachim-breitner.de>

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



From mail at joachim-breitner.de  Thu Dec 17 17:32:10 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Dec 2020 18:32:10 +0100
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <653c4a724e47a1e46fff609a6953889566b50cf2.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAGK9nuqN3B93MojfY7srtdVQ-XmgubmQ_DEfKEozbUhoMReyKg@mail.gmail.com>
 <653c4a724e47a1e46fff609a6953889566b50cf2.camel@joachim-breitner.de>
Message-ID: <5f797e209696b2755f7033ff2f5cca8e8ee5dae1.camel@joachim-breitner.de>

Am Donnerstag, den 17.12.2020, 18:31 +0100 schrieb Joachim Breitner:
> We don't have a ✓ from Cale, Eric, SPJ.

and Tom, sorry.


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



From simonpj at microsoft.com  Thu Dec 17 17:37:25 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Dec 2020 17:37:25 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <653c4a724e47a1e46fff609a6953889566b50cf2.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAGK9nuqN3B93MojfY7srtdVQ-XmgubmQ_DEfKEozbUhoMReyKg@mail.gmail.com>
 <653c4a724e47a1e46fff609a6953889566b50cf2.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02229580F95837721855CFCDADC49@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 17 December 2020 17:31
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438504
|  da9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743
|  8231073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
|  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ytdAFFyUzw42q4CCTc
|  gReYA7L4aR1vmwyxi6Tw8J92w%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438
|  504da9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7438231073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8APGVhhAgaiyMJU
|  bMPULTeXMxw0iI1TR88S4A6O7Q4A%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C32c25db438504da
|  9ade908d8a2b19eaf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374382
|  31073280576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0jakyN5fn6rE1MNnEpGE
|  iQBtyL695b1aH48%2BEKyi%2B80%3D&amp;reserved=0

From cgibbard at gmail.com  Thu Dec 17 17:47:11 2020
From: cgibbard at gmail.com (Cale Gibbard)
Date: Thu, 17 Dec 2020 12:47:11 -0500
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
Message-ID: <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>

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 <marlowsd at gmail.com> 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 <mail at joachim-breitner.de> 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-ghc2021.rst#data
>> 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?path=43548.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 at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Fri Dec 18 03:43:01 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 17 Dec 2020 21:43:01 -0600
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
Message-ID: <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>

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 <cgibbard at gmail.com> 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 <marlowsd at gmail.com> 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 <mail at joachim-breitner.de> 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-ghc2021.rst#data
>>> 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?path=43548.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 at joachim-breitner.de
>>>  http://www.joachim-breitner.de/
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From trupill at gmail.com  Fri Dec 18 07:18:56 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 18 Dec 2020 07:18:56 +0000
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOuhjY_kXK89wZhoOavTMTNMFH6azyXAMcF95MhkCGpsmA@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
 <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>
 <CAHnFXOtp1m7hNvnEELryJz9G+JFg4CxXfz0ERJYurvvFPdJJcg@mail.gmail.com>
 <CAHnFXOuhjY_kXK89wZhoOavTMTNMFH6azyXAMcF95MhkCGpsmA@mail.gmail.com>
Message-ID: <CAHnFXOs9CUkU4E4Pv7ywgSEMJZkGtT-Xo8sh6Wx+Ud+-FsLf2Q@mail.gmail.com>

 Dear Committee,
I think we can mark this as accepted now.

Regards,
Alejandro

On 15 Dec 2020 at 21:06:51, Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> It seems that everything is solve now. Are the any further objections?
> Otherwise I guess in a couple of days we can mark this as accepted.
>
> Regards,
> Alejandro
>
> On 11 Dec 2020 at 22:39:39, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>>
>>
>> On 11 Dec 2020 at 21:35:20, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> Sorry -- I've lost track here a bit. What's the issue with the grammar?
>>>
>>
>> In this comment
>> https://github.com/ghc-proposals/ghc-proposals/pull/370#issuecomment-741785189
>> :
>>
>> Syntax: the form btype [ {modifier} -> type ] seems to allow one or zero
>>> modifiers but not two. Or do I misunderstand the braces? Spell it out please
>>>
>>
>> Regards,
>> Alejandro
>>
>>
>>> I'm quite happy to label this experimental. The key aspect of the
>>> proposal is just to outline a way forward with adding syntax.
>>>
>>> Richard
>>>
>>> On Dec 10, 2020, at 4:29 AM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>> Should we mark them as “accepted” with the following text?
>>>
>>> The Committee accepts this proposal as experimental. This means that the
>>>> Committee expects changes to this feature in the future, maybe as the
>>>> result of other accepted proposals.
>>>>
>>>
>>> If you agree, then we can accept this proposal once a little remaining
>>> issue with the grammar has been clarified.
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> On 10 Dec 2020 at 09:59:02, Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>
>>>> That was the point of my previous email: accept, and
>>>> accept-as-experimental are actually one and the same.
>>>>
>>>> Objectively, yes.  But I think it helps users to advertise a feature as
>>>> experimental.  It’s a signal to users that this feature is, well,
>>>> experimental.  It is more likely to change.
>>>>
>>>> It’s only an indication not a clear distinction.  But I find it helpful.
>>>>
>>>> For me, it also reflects how I evaluate the proposal.  For a change to
>>>> a well-established feature, we have a lot of experience in how people use
>>>> that feature.
>>>>
>>>> For experimental features we don’t.  Example: defaulting for
>>>> matchability for unsaturated type families.  We don’t have unsaturated type
>>>> families right now, so we don’t have any code that uses them, and hence
>>>> zero in-the-wild experience about matchability defaulting.  We shouldn’t
>>>> spend ages arguing the toss – just trust Csongor’s judgement and give it a
>>>> try, but advertising that details may change.
>>>>
>>>> Simon
>>>>
>>>>
>>>> *From:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>> *Sent:* 10 December 2020 08:06
>>>> *To:* Alejandro Serrano Mena <trupill at gmail.com>
>>>> *Cc:* Richard Eisenberg <rae at richarde.dev>;
>>>> ghc-steering-committee at haskell.org; Simon Peyton Jones <
>>>> simonpj at microsoft.com>
>>>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>>>> Recommendation: Acceptance
>>>>
>>>>
>>>> That was the point of my previous email: accept, and
>>>> accept-as-experimental are actually one and the same.
>>>>
>>>>
>>>> What Simon is driving at, I think, is: depending on what the proposal
>>>> is about, we want to apply more or less strict standard of acceptance (if a
>>>> proposal is about fixing something in an existing feature, then we better
>>>> be rather sure that it is indeed an improvement; but if it's about adding
>>>> something new in an untrodden territory, then we can't really be sure, and
>>>> it's worth experimenting with).
>>>>
>>>>
>>>> On Wed, Dec 9, 2020 at 9:17 PM Alejandro Serrano Mena <
>>>> trupill at gmail.com> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> As the shepherd of this proposal, I’m quite confused about what the
>>>> outcome should be. The ghc-proposals README states that:
>>>>
>>>>
>>>> Acceptance of the proposal implies that the implementation will be
>>>> accepted into GHC provided it is well-engineered, well-documented, and does
>>>> not complicate the code-base too much.
>>>>
>>>>
>>>>
>>>> Most of the Committee seems to lean towards “this seems OK right now,
>>>> but we don’t want to be locked” or “mark this as experimental”. However,
>>>> there’s no such notion as “accept as experimental”. Furthermore, as it
>>>> stands the proposal gives some syntax, and then asks any new extensions to
>>>> use that syntax; so it cannot be completely thought as a feature by itself.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Alejandro
>>>>
>>>> On 9 Dec 2020 at 15:59:43, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>> It's always possible to change. I don't think accepting a proposal
>>>> means (or ought to mean) that we are locked into anything. Accepting a
>>>> proposal means that we won't oppose a design-related argument to a PR that
>>>> implements (part or all of) an accepted proposal.
>>>>
>>>>
>>>> I don't know how to quantify the degree of confidence that we have in
>>>> the stability of a proposal. Here we are all saying: this is better than
>>>> anything so far, and we rather need something like this to be a thing, but
>>>> it's really a shot in the dark. And this lack of confidence will be
>>>> reflected in the manual description. But even if we are confident in the
>>>> stability of a proposal, it may very well happen that it changes
>>>> dramatically, even soon.
>>>>
>>>>
>>>> On Wed, Dec 9, 2020 at 2:55 PM Simon Peyton Jones via
>>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>>
>>>> I’ve replied on GitHub.  Generally in favour.  But mark it as
>>>> experimental… I don’t want to be locked into “we decided on this in Dec
>>>> 2020 so now it’s too late”.  WE can learn from experience.
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>> *From:* ghc-steering-committee <
>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>> Serrano Mena
>>>> *Sent:* 03 December 2020 20:17
>>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>>> *Cc:* ghc-steering-committee at haskell.org
>>>> *Subject:* Re: [ghc-steering-committee] #370: Syntax for Modifiers,
>>>> Recommendation: Acceptance
>>>>
>>>>
>>>> Dear Committee,
>>>>
>>>>
>>>> Richard has requested for us to consider the new version of this
>>>> proposal. As opposed to the previous version, this one is only about
>>>> reserving syntax for “modifiers”, which at the beginning would be used for
>>>> things like linearity or matchability of arrows.
>>>>
>>>>
>>>> I think this is a good proposal, and one which would save us from
>>>> re-considering syntax for every possible extension (and if linearity
>>>> appears before the arrow and matchability after it, where would a future
>>>> dimension go?). Thus I keep recommending acceptance on this new incarnation.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Alejandro
>>>>
>>>>
>>>> On 30 Nov 2020 at 20:52:26, Richard Eisenberg <rae at richarde.dev> wrote:
>>>>
>>>> To my surprise, I found myself leaning against. So I updated and
>>>> simplified the proposal to remove Modifier. This makes modifiers a bit more
>>>> magical, but more likely to actually work in practice. The type inference
>>>> story previously may have been intractable.
>>>>
>>>>
>>>> I've requested that the committee consider the updates in parallel with
>>>> community feedback.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Richard
>>>>
>>>>
>>>> On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <trupill at gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> After some discussion in the GitHub thread, changes are going to arrive
>>>> to the proposal. I think the best is to send the proposal back to the
>>>> “Needs revision” state.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Alejandro
>>>>
>>>>
>>>> On 29 Nov 2020 at 23:12:44, Eric Seidel <eric at seidel.io> wrote:
>>>>
>>>> I left a few comments and questions on the PR itself, but I'm leaning
>>>> towards rejecting the proposal in its current form as well. This doesn't
>>>> (yet) feel like a generic mechanism, in particular because the only
>>>> modifier that has been specified would be deeply wired into GHC itself.
>>>>
>>>> On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano
>>>>
>>>> Mena:
>>>>
>>>> > Dear all,
>>>>
>>>> > This proposal suggests adding syntax for a general notion of
>>>>
>>>> > modifiers, like the ones we’ve been talking about lately affecting
>>>>
>>>> > linearity or matchability of arrows. For example, if linear types and
>>>>
>>>> > unsaturated families are accepted as they stand, we would have `Int
>>>>
>>>> > #1 -> @U Bool` (or something like that), whereas with this proposal
>>>>
>>>> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.
>>>>
>>>> >
>>>>
>>>> > Since the amount of modifiers is likely to increase in the future, I
>>>>
>>>> > think it’s a great idea to agree and reserve such syntax, instead of
>>>>
>>>> > coming up with different ways on each proposal. I thus recommend
>>>>
>>>> > acceptance of this proposal.
>>>>
>>>> >
>>>>
>>>> > The proposal itself:
>>>>
>>>> > (1) introduces syntax for modifiers in types and defines how to
>>>>
>>>> > type/kind check them,
>>>>
>>>> > (2) reserved such syntax for other uses in declarations and terms.
>>>>
>>>> >
>>>>
>>>> > I think the proposal still has its merits only with (1), even though
>>>>
>>>> > I lean towards accepting both parts of it.
>>>>
>>>>
>>>>
>>>> I like the idea of reserving syntax here, but parts of the proposal
>>>>
>>>> smell a bit like premature generalization to me. Are we confident that
>>>>
>>>> all annotations we eventually would like to use with this feature can
>>>>
>>>> be expressed as types of a kind that is an instance of Modifier? Or
>>>>
>>>> should we reserve the ability to have annotations that don't fit that
>>>>
>>>> model?
>>>>
>>>>
>>>>
>>>> Would we ever have annotation that may affect phases earlier than than
>>>>
>>>> typechecking? What if we want to use (%type e) and (%data e) to help
>>>>
>>>> with the SingleNamepace issues? Look like useful annotations to me, but
>>>>
>>>> I am not sure if they fit the framework proposed here.
>>>>
>>>>
>>>>
>>>> The fact that we special-case %1 supports that.
>>>>
>>>>
>>>>
>>>> The proposal explicitly has to state “No modifier polymorphism!”. But
>>>>
>>>> isn't that indication that using the type system to model the various
>>>>
>>>> modifiers might be the wrong tool?
>>>>
>>>>
>>>>
>>>> I wonder if there is a way where the %(…) on it’s own only reserve
>>>>
>>>> syntax, and the various uses of that syntax can be disambiguated
>>>>
>>>> _statically_ based on the content of ….
>>>>
>>>>
>>>>
>>>> Not great syntax, because not concise, enough, but morally I’d feel
>>>>
>>>> more at ease with
>>>>
>>>>
>>>>
>>>>   Int %(multiplicity Many) -> Int
>>>>
>>>>   Int %(multiplicity 1) -> Int
>>>>
>>>>   Int %(multiplicity m) -> Int
>>>>
>>>>
>>>>
>>>> where multiplicity is a modifier keyword, to express the existing
>>>>
>>>> features (including implicit generalization of m). Then we can extend
>>>>
>>>> this to
>>>>
>>>>
>>>>
>>>>   Int %oneShot -> Int
>>>>
>>>>
>>>>
>>>> and
>>>>
>>>>
>>>>
>>>>   Int %(matchability M) -> Int
>>>>
>>>>
>>>>
>>>> and maybe even
>>>>
>>>>
>>>>
>>>>   foo (%type [a]) -- where foo :: forall a -> ()
>>>>
>>>>
>>>>
>>>> which is a modifier that
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So at the moment, I am inclined to reject this proposal, until I am
>>>>
>>>> convinced that we are not painting ourselves into a “all modifiers are
>>>>
>>>> types of special kinds and that’s all the syntax and behaviour we ever
>>>>
>>>> need” corner.
>>>>
>>>>
>>>>
>>>> Minor detail: If we can annotate infix use of the (->) “type operator”,
>>>>
>>>> should we also be able to annotate other infix operators, i.e.
>>>>
>>>>
>>>>
>>>>   constr ::= (btype | ! atype) {modifier} conop (btype | ! atype)
>>>>
>>>>   infixexp ::= lexp {modifier} qop infixexp
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Joachim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Joachim Breitner
>>>>
>>>>   mail at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904133795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EOafNT2JtRWPODqAKfG3TNH3xqPEe3%2B5ThuYLbjYPiY%3D&reserved=0>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> ghc-steering-committee mailing list
>>>>
>>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904143751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSx3i0ZoLHVnh6rfNzv1qcJwMCXnRxM6iD%2FxYBRTJP8%3D&reserved=0>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at 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%7C97291bd458234e28f0aa08d89ce27f4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637431843904153698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEoElFpNjneP9rKR808eGaYKwaV66tLHiN0Tbra0GkA%3D&reserved=0>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201218/dfad4d5b/attachment-0001.html>

From simonpj at microsoft.com  Fri Dec 18 08:59:39 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 Dec 2020 08:59:39 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
Message-ID: <VI1PR83MB0222F589793598EA191C812BADC39@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <cgibbard at gmail.com> 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 <marlowsd at gmail.com>
|  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 <mail at joachim-
|  breitner.de> 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&amp;data=04%7C01%7Csimonpj%40microsoft.c
|  >>>
|  om%7C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011
|  >>>
|  db47%7C1%7C0%7C637438598033649008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
|  >>>
|  4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
|  >>>
|  sdata=NhvlIwuLVahY2XRkBXrPp08jGad5V%2B3dyUxxRfScuVI%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f71
|  >>>
|  1c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
|  >>>
|  0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  >>>
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EBMu9
|  >>> n%2BX917NG5L7k7tJMDDnxlclzO0LNAvimEettq4%3D&amp;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 at joachim-breitner.de
|  >>>
|  >>>
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
|  >>> .joachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7
|  >>>
|  C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47
|  >>>
|  %7C1%7C0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
|  >>>
|  AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
|  >>> a=5FRqUoTh1wBOS8Hrj6L5CK9uTtsXCDc2U4zVMKQ2UpY%3D&amp;reserved=0
|  >>>
|  >>>
|  >>> _______________________________________________
|  >>> ghc-steering-committee mailing list
|  >>> ghc-steering-committee at haskell.org
|  >>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  >>> il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committ
|  >>>
|  ee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da
|  >>>
|  08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385980
|  >>>
|  33659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
|  >>>
|  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP
|  >>> 7KMC661xIvVCip588OGEEUj0zI%3D&amp;reserved=0
|  >>
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org
|  >>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
|  >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee
|  >>
|  &amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da08d
|  >>
|  8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743859803365
|  >>
|  9005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
|  >>
|  TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP7KMC66
|  >> 1xIvVCip588OGEEUj0zI%3D&amp;reserved=0
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at 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&amp;sdata=O%2FGAauT8sznxenlzP7KMC661xIvVC
|  > ip588OGEEUj0zI%3D&amp;reserved=0
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb
|  881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385
|  98033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP7
|  KMC661xIvVCip588OGEEUj0zI%3D&amp;reserved=0

From mail at joachim-breitner.de  Fri Dec 18 09:14:00 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 18 Dec 2020 10:14:00 +0100
Subject: [ghc-steering-committee] #370: Syntax for Modifiers,
 Recommendation: Acceptance
In-Reply-To: <CAHnFXOs9CUkU4E4Pv7ywgSEMJZkGtT-Xo8sh6Wx+Ud+-FsLf2Q@mail.gmail.com>
References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de>
 <CAHnFXOtSbtbzzN1FwfnE+saDKJCdRTMOqjhddn4zmvG1a1X5iQ@mail.gmail.com>
 <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de>
 <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com>
 <CAHnFXOtDyneEm+4LqJ0kLqKkRPA6sF4-E4udKavVjeYpc_pRSw@mail.gmail.com>
 <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com>
 <CAHnFXOsEUDsi3h4y08Rgmn4+VFMG_aDcgDncwuY+C9qe8KjFSA@mail.gmail.com>
 <VI1PR83MB0222A0761C01E9401506FE89ADCC1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAH6fHQnTNPEo54u2v36wTKL77k1nVuykdnUeOYkBFO3hJz39EA@mail.gmail.com>
 <CAHnFXOvLH8K1S57o7t4U3bfmA9DPLmf=jZsOD4KrQo4qKXZvKg@mail.gmail.com>
 <CAH6fHQkO0Sbzefk6a_FU=NEkkQMC0FT4kkLSfDqicKYfz6k7gw@mail.gmail.com>
 <VI1PR83MB02222673D1EAE3F6491BF254ADCB1@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOs7c5GbDS8M6X_WOTeAbVCp4Whb=z_Rgn1O60gPgXNwqQ@mail.gmail.com>
 <010f01765383e128-85026b3c-b378-4312-8533-173aca37e586-000000@us-east-2.amazonses.com>
 <CAHnFXOtp1m7hNvnEELryJz9G+JFg4CxXfz0ERJYurvvFPdJJcg@mail.gmail.com>
 <CAHnFXOuhjY_kXK89wZhoOavTMTNMFH6azyXAMcF95MhkCGpsmA@mail.gmail.com>
 <CAHnFXOs9CUkU4E4Pv7ywgSEMJZkGtT-Xo8sh6Wx+Ud+-FsLf2Q@mail.gmail.com>
Message-ID: <eb41c2d5408aba1c1e7c88762dc8764a37a508c4.camel@joachim-breitner.de>

Hi,

Am Freitag, den 18.12.2020, 07:18 +0000 schrieb Alejandro Serrano Mena:
> I think we can mark this as accepted now.


merged.

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



From i.am.tom.harding at gmail.com  Fri Dec 18 13:26:03 2020
From: i.am.tom.harding at gmail.com (Tom Harding)
Date: Fri, 18 Dec 2020 13:26:03 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <VI1PR83MB0222F589793598EA191C812BADC39@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
 <VI1PR83MB0222F589793598EA191C812BADC39@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <AF18D65C-9629-428E-B912-5F03C2734C82@gmail.com>

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 <ghc-steering-committee at haskell.org> 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 <cgibbard at gmail.com> 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 <marlowsd at gmail.com>
> |  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 <mail at joachim-
> |  breitner.de> 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&amp;data=04%7C01%7Csimonpj%40microsoft.c
> |  >>>
> |  om%7C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011
> |  >>>
> |  db47%7C1%7C0%7C637438598033649008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> |  >>>
> |  4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
> |  >>>
> |  sdata=NhvlIwuLVahY2XRkBXrPp08jGad5V%2B3dyUxxRfScuVI%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f71
> |  >>>
> |  1c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> |  >>>
> |  0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> |  >>>
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EBMu9
> |  >>> n%2BX917NG5L7k7tJMDDnxlclzO0LNAvimEettq4%3D&amp;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 at joachim-breitner.de
> |  >>>
> |  >>>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> |  >>> .joachim-
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7
> |  >>>
> |  C886f711c1ffc4fb881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47
> |  >>>
> |  %7C1%7C0%7C637438598033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> |  >>>
> |  AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> |  >>> a=5FRqUoTh1wBOS8Hrj6L5CK9uTtsXCDc2U4zVMKQ2UpY%3D&amp;reserved=0
> |  >>>
> |  >>>
> |  >>> _______________________________________________
> |  >>> ghc-steering-committee mailing list
> |  >>> ghc-steering-committee at haskell.org
> |  >>>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> |  >>> il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committ
> |  >>>
> |  ee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da
> |  >>>
> |  08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385980
> |  >>>
> |  33659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> |  >>>
> |  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP
> |  >>> 7KMC661xIvVCip588OGEEUj0zI%3D&amp;reserved=0
> |  >>
> |  >> _______________________________________________
> |  >> ghc-steering-committee mailing list
> |  >> ghc-steering-committee at haskell.org
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
> |  >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee
> |  >>
> |  &amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb881da08d
> |  >>
> |  8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63743859803365
> |  >>
> |  9005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> |  >>
> |  TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP7KMC66
> |  >> 1xIvVCip588OGEEUj0zI%3D&amp;reserved=0
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at 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&amp;sdata=O%2FGAauT8sznxenlzP7KMC661xIvVC
> |  > ip588OGEEUj0zI%3D&amp;reserved=0
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C886f711c1ffc4fb
> |  881da08d8a3070f8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374385
> |  98033659005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=O%2FGAauT8sznxenlzP7
> |  KMC661xIvVCip588OGEEUj0zI%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From arnaud.spiwack at tweag.io  Fri Dec 18 13:51:01 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 18 Dec 2020 14:51:01 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
	kialo.com
In-Reply-To: <CANsrgPJe=TtZS9dHe8NtokbfR98ZZS=iw7+OP37KyRiPzx8pXQ@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <VI1PR83MB0222EB9AB1BF66BC855814EFADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAHnFXOsZnD_0z7edc2jLd6d-_gktrFBhiFo5EyhiYz2vv9d0Mw@mail.gmail.com>
 <VI1PR83MB022253C5A17CBAAAA2180673ADC69@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CANsrgP+=3cHMXVLD=SiiuvB89ZdgDZrT74Qp65TzmXxG4esgxA@mail.gmail.com>
 <CAH6fHQk1g2_Z7esrbbjyS-D1jT8zmOdk0JvEebGaBhVUbLGmog@mail.gmail.com>
 <CANsrgP+7iF6r1yOC3mVsvX1eZMAjLGDYQcTs6p68XQ3jm3g8NQ@mail.gmail.com>
 <CAH6fHQnqE=+hcXMV0c35kaPMxA00gXdbAWT-5SCE477AXsoggQ@mail.gmail.com>
 <CANsrgPJe=TtZS9dHe8NtokbfR98ZZS=iw7+OP37KyRiPzx8pXQ@mail.gmail.com>
Message-ID: <CAH6fHQnY3_dGKxU=zWJTbc+11saLv7V2c9LigOrBx2nf9uzv6Q@mail.gmail.com>

Dear all,

Since the conversation is still raging (and still fascinating), let me let
everybody know that I will be off my email in the next two weeks.

Let me wish everybody a great holiday season. And talk to you all again in
2021.

Best,
Arnaud

On Thu, Dec 17, 2020 at 5:53 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On Thu, 17 Dec 2020 at 16:42, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> On Thu, Dec 17, 2020 at 5:24 PM Simon Marlow marlowsd at gmail.com
>> <http://mailto:marlowsd at 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 :: _ -> _
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201218/8a1379f8/attachment-0001.html>

From marlowsd at gmail.com  Fri Dec 18 14:07:11 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 18 Dec 2020 14:07:11 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
Message-ID: <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>

On Fri, 18 Dec 2020 at 03:43, Eric Seidel <eric at seidel.io> 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.


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

Cheers
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 <cgibbard at gmail.com> 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 <marlowsd at gmail.com> 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 <
> mail at joachim-breitner.de> 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-ghc2021.rst#data
> >>> 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?path=43548.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 at joachim-breitner.de
> >>>  http://www.joachim-breitner.de/
> >>>
> >>>
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201218/9addb4da/attachment.html>

From eric at seidel.io  Fri Dec 18 16:44:21 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 18 Dec 2020 10:44:21 -0600
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
 <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>
Message-ID: <1d2494f5-10ff-403a-aa7d-5758f604c26a@www.fastmail.com>

On Fri, Dec 18, 2020, at 08:07, Simon Marlow wrote:
> On Fri, 18 Dec 2020 at 03:43, Eric Seidel <eric at seidel.io> 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

From mail at joachim-breitner.de  Sat Dec 19 20:40:31 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 19 Dec 2020 21:40:31 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
Message-ID: <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>

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



From eric at seidel.io  Sat Dec 19 21:02:45 2020
From: eric at seidel.io (Eric Seidel)
Date: Sat, 19 Dec 2020 15:02:45 -0600
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
Message-ID: <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>

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 <mail at joachim-breitner.de> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at richarde.dev  Sat Dec 19 22:08:25 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 19 Dec 2020 22:08:25 +0000
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
Message-ID: <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>

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 <eric at seidel.io> 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 <mail at joachim-breitner.de> 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 at joachim-breitner.de
>> http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From iavor.diatchki at gmail.com  Sat Dec 19 22:35:09 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 19 Dec 2020 14:35:09 -0800
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>

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 <rae at richarde.dev> 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 <eric at seidel.io> 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 <mail at joachim-breitner.de>
> 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 at joachim-breitner.de
> >> http://www.joachim-breitner.de/
> >>
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201219/f8f855ee/attachment-0001.html>

From trupill at gmail.com  Sun Dec 20 07:48:22 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sun, 20 Dec 2020 08:48:22 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
 <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
Message-ID: <CAHnFXOsZtfuFscBeZW0ozizw1U4DOu7Tnh++TY4DNR0f=scEhg@mail.gmail.com>

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 <iavor.diatchki at gmail.com>
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 <rae at richarde.dev>
> 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 <eric at seidel.io> 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 <mail at joachim-breitner.de>
>> 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 at joachim-breitner.de
>> >> http://www.joachim-breitner.de/
>> >>
>> >>
>> >> _______________________________________________
>> >> ghc-steering-committee mailing list
>> >> ghc-steering-committee at haskell.org
>> >>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201220/48988b1b/attachment.html>

From mail at joachim-breitner.de  Sun Dec 20 15:54:25 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 20 Dec 2020 16:54:25 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
 <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
Message-ID: <4e0f673ecc757e4e507bddd94693e0c024e320ba.camel@joachim-breitner.de>

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-ghc2021.rst
is up to date, so all the extensions with a bold number in the “Votes”
column (≥ 8).


Cheers,
Joachim

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



From mail at joachim-breitner.de  Sun Dec 20 15:55:56 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 20 Dec 2020 16:55:56 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <CAHnFXOsZtfuFscBeZW0ozizw1U4DOu7Tnh++TY4DNR0f=scEhg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
 <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
 <CAHnFXOsZtfuFscBeZW0ozizw1U4DOu7Tnh++TY4DNR0f=scEhg@mail.gmail.com>
Message-ID: <d27b136ac37385bdd45f8c6f8101a32c1e505ea8.camel@joachim-breitner.de>

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



From iavor.diatchki at gmail.com  Sun Dec 20 18:01:48 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 20 Dec 2020 10:01:48 -0800
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <d27b136ac37385bdd45f8c6f8101a32c1e505ea8.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
 <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
 <CAHnFXOsZtfuFscBeZW0ozizw1U4DOu7Tnh++TY4DNR0f=scEhg@mail.gmail.com>
 <d27b136ac37385bdd45f8c6f8101a32c1e505ea8.camel@joachim-breitner.de>
Message-ID: <CAGK9nur6XHLNtwQBwp3XpXsjn=XZAVYYUkd-yvkkQyxf32VoFw@mail.gmail.com>

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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201220/ed232263/attachment.html>

From mail at joachim-breitner.de  Sun Dec 20 18:21:01 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 20 Dec 2020 19:21:01 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <CAGK9nur6XHLNtwQBwp3XpXsjn=XZAVYYUkd-yvkkQyxf32VoFw@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <D5F09757-B8FC-4115-949B-61749CA79FD8@seidel.io>
 <010f01767d0bfb02-892464df-1ce3-4677-aed0-01f9b62c57e8-000000@us-east-2.amazonses.com>
 <CAGK9nur9=sGBprma+C4AGt5-8wjJ9QwPG27LgHVidb8iScpPRg@mail.gmail.com>
 <CAHnFXOsZtfuFscBeZW0ozizw1U4DOu7Tnh++TY4DNR0f=scEhg@mail.gmail.com>
 <d27b136ac37385bdd45f8c6f8101a32c1e505ea8.camel@joachim-breitner.de>
 <CAGK9nur6XHLNtwQBwp3XpXsjn=XZAVYYUkd-yvkkQyxf32VoFw@mail.gmail.com>
Message-ID: <797dcee1d99c2b700525c98a515d8c67a9671b30.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 20.12.2020, 10:01 -0800 schrieb Iavor Diatchki:
> Just for fun, my two biggest "disappointments" are:

>    * RecordWildCards not on by default, because it is a completely opt in feature, which is extremely convenient on occasion

I share that one.

And for the same reasons I am disappointed about (in that order):

 * UnicodeSyntax
 * TupleSyntax
 * LambdaCase

and more generally that we don’t have the option of including an
PatternSignatures extension that contains the a non-controversial part
of the ScopedTypeVaraibles kitchen sink (and maybe I will retry a form
of #119 so that next round we _can_ enable signatures in patterns).

Cheers,
Joachim



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



From marlowsd at gmail.com  Mon Dec 21 18:19:36 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 21 Dec 2020 18:19:36 +0000
Subject: [ghc-steering-committee] GHC2021 extensions should be
 sufficient for early intermediate Haskellers
In-Reply-To: <CAH6fHQmJXZh4C1k-2-PzqBpGdPbe0iRaTJCO7jBfj0qEZhCM5g@mail.gmail.com>
References: <010f01766847fc53-f83cb24d-7717-44a2-a15b-4e275a7d0416-000000@us-east-2.amazonses.com>
 <CAH6fHQmJXZh4C1k-2-PzqBpGdPbe0iRaTJCO7jBfj0qEZhCM5g@mail.gmail.com>
Message-ID: <CANsrgPJDsPaTUF8=9M6nt2wNegiVsUJw0_MFnLy9s0GLmWWENw@mail.gmail.com>

On Thu, 17 Dec 2020 at 08:15, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> I don't agree with this sentiment at all, to be honest. In my opinion, the
> ultimate fate of every extension is to be rolled into the standard or to be
> relegated to the bins of history. The idea of having various levels of
> languages based on how advanced they are perceived to be sounds
> extraordinary to me (also quite a bit patronising).
>
> Generally speaking, you opt in to a feature by using it. GHC2021 should
> not have features that we, as a community, don't recommend using (the
> bins-of-history ones); but, surely, TypeFamilies is not one of these. It is
> not to say that GHC2021 should have TypeFamilies, but that them being
> perceived as advanced is not, in my opinion, a relevant criterion. We
> should be asking, instead, whether it is ready.
>

I strongly agree with Arnuad here.

Cheers
Simon



>
> On Tue, Dec 15, 2020 at 10:22 PM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> Hi all,
>>
>> In thinking about how I feel about TypeFamilies (and why I lean against
>> inclusion), I realized I had a new criterion:
>>
>> * GHC2021 extensions should be sufficient for early-intermediate
>> Haskellers
>>
>> Today, users have to enable a number of extensions just to get basic work
>> done (I'm looking at you, FlexibleContexts). So they learn just to take
>> whatever suggestion is presented to them in an error message and apply it.
>>
>> But if extensions were considered more exotic, then users might not be so
>> willing to add an extension. They would have to consider whether they
>> really want to opt into more challenging error messages and a wider
>> horizon. TypeFamilies is an extension that significantly widens the
>> horizon, but also invites new scary error messages. I think it should be
>> opt in. But this gatekeeping works only if users will be thoughtful about
>> enabling the extension; thus my new criterion.
>>
>> What do we think about this?
>>
>> (I thought of putting this on Kialo, but it didn't seem to fit the setup
>> there. Maybe I've erred in not just blasting ahead.)
>>
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201221/10b5fc55/attachment.html>

From simonpj at microsoft.com  Mon Dec 21 19:50:49 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Dec 2020 19:50:49 +0000
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>

Thanks Joachim

I don't want to force this debate to a conclusion tomorrow.  Many people have stopped work for the Xmas holidays, and just before Xmas is a bad time to declare game over.

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/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing

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.

I suggest we proceed as follows:

* Check the document is up to date (Joachim might you manage to do that?)

* 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?

Simon


| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 19 December 2020 20:41
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] #380 GHC2021: How to proceed?
| 
| 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 at joachim-breitner.de
| 
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
| im-
| breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C543f55b21d8c40
| c1070708d8a45e5f0e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374400725
| 43720721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
| iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cSe%2FPnQO2Sj5F%2BLFSwziYKup6jl
| rsr2YdPPw8k0Xm%2Fc%3D&amp;reserved=0
| 
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C543f55b21d8c40c1070
| 708d8a45e5f0e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637440072543720
| 721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
| 1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LSCX57qhrSHf9aR2g6cYtTciw9SFKVBVQxXU
| m3sGh0s%3D&amp;reserved=0

From mail at joachim-breitner.de  Mon Dec 21 20:26:04 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 21 Dec 2020 21:26:04 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <602220b62cf41629fddeac648bde36fff290767d.camel@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/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing
> 
> 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-ghc2021.rst#data

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



From simonpj at microsoft.com  Tue Dec 22 10:05:49 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 22 Dec 2020 10:05:49 +0000
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02223CFFD4E22D6243B89A40ADDF9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 21 December 2020 20:26
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%
|  >
|  7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%
|  >
|  7C1%7C0%7C637441791891403803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
|  >
|  DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sXj
|  > Sq8Fwla6AysnF9oW5QObfyRGaNcsSVx%2Bh5046Cqg%3D&amp;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&amp;data=04%7
|  C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f
|  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637441791891413801%7CUnknown%7
|  CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
|  CI6Mn0%3D%7C1000&amp;sdata=79QzkT3UBoasQjYNBBu9aBy1Q4e1yVPoLOS08cZgnYg
|  %3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0
|  b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1UtWLiYPCLx
|  P4jNf9K9beUXveTRp8SiG6U%2FFSUK3YXo%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a
|  7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YZypxIrkQlmvj0s
|  MY8tiucfKpZUwQ%2BlUng%2BEKzJsZMA%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c
|  5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374417
|  91891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RkA6zmdd%2BmBPP9yslk
|  Mn5yVfWt58hGNjuhAdzel%2Fi6c%3D&amp;reserved=0

From iavor.diatchki at gmail.com  Wed Dec 23 00:08:47 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 22 Dec 2020 16:08:47 -0800
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <VI1PR83MB02223CFFD4E22D6243B89A40ADDF9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
 <VI1PR83MB02223CFFD4E22D6243B89A40ADDF9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nup4jF9+QzZsaZNEwiokvcZ062b4YAgTCxSAipqcKa2_tA@mail.gmail.com>

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 <ghc-steering-committee at haskell.org> 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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 21 December 2020 20:26
> |  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%
> |  >
> |  7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%
> |  >
> |  7C1%7C0%7C637441791891403803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> |  >
> |  DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sXj
> |  > Sq8Fwla6AysnF9oW5QObfyRGaNcsSVx%2Bh5046Cqg%3D&amp;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&amp;data=04%7
> |  C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f
> |  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637441791891413801%7CUnknown%7
> |  CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> |  CI6Mn0%3D%7C1000&amp;sdata=79QzkT3UBoasQjYNBBu9aBy1Q4e1yVPoLOS08cZgnYg
> |  %3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0
> |  b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> |  7C637441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> |  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1UtWLiYPCLx
> |  P4jNf9K9beUXveTRp8SiG6U%2FFSUK3YXo%3D&amp;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 at joachim-breitner.de
> |
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  oachim-
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a
> |  7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> |  7441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YZypxIrkQlmvj0s
> |  MY8tiucfKpZUwQ%2BlUng%2BEKzJsZMA%3D&amp;reserved=0
> |
> |
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c
> |  5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374417
> |  91891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RkA6zmdd%2BmBPP9yslk
> |  Mn5yVfWt58hGNjuhAdzel%2Fi6c%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201222/faa35e3f/attachment.html>

From mail at joachim-breitner.de  Wed Dec 23 08:37:25 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 23 Dec 2020 09:37:25 +0100
Subject: [ghc-steering-committee] #380 GHC2021: How to proceed?
In-Reply-To: <CAGK9nup4jF9+QzZsaZNEwiokvcZ062b4YAgTCxSAipqcKa2_tA@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
 <VI1PR83MB02223CFFD4E22D6243B89A40ADDF9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <CAGK9nup4jF9+QzZsaZNEwiokvcZ062b4YAgTCxSAipqcKa2_tA@mail.gmail.com>
Message-ID: <739124b6979161be2eb773fe08d71f8e2bba7833.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 22.12.2020, 16:08 -0800 schrieb Iavor Diatchki:
> here is another update to my votes.  The change is mostly to eliminate all `maybe` with a concrete `yes` or `no`.

thanks!

This affects the the “critical section” as follows:

StandaloneKindSignatures goes from barely in  to safely in.
ScopedTypeVariables      goes from barley out to barely in
TupleSections            goes from barely out to barely in.
OverloadedStrings        goes from safely out to barely out

There are now 4 more extensions that have 100% of the votes, which is
probably a good thing.

I have updated
https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit
accordingly.

Cheers,
Joachim



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



From mail at joachim-breitner.de  Wed Dec 23 09:38:39 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 23 Dec 2020 10:38:39 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Structured summary
In-Reply-To: <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
Message-ID: <183fc007270be58116118f2d6abcf4402336e6f2.camel@joachim-breitner.de>

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/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing
> > 
> > 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-ghc2021.rst#data


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-ghc2021.rst#executive-summary
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Wed Dec 23 10:07:51 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 23 Dec 2020 10:07:51 +0000
Subject: [ghc-steering-committee] #380 GHC2021: Structured summary
In-Reply-To: <183fc007270be58116118f2d6abcf4402336e6f2.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
 <183fc007270be58116118f2d6abcf4402336e6f2.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB022252776A8CB3ADE8EB3F70ADDE9@VI1PR83MB0222.EURPRD83.prod.outlook.com>

|  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.)

TypeApplications has nothing to do with Patterns.

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

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

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 23 December 2020 09:39
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] #380 GHC2021: Structured summary
|  
|  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
|  > >
|  cs.google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM
|  > >
|  4VnANa8%2Fedit%3Fusp%3Dsharing&amp;data=04%7C01%7Csimonpj%40microsof
|  > >
|  t.com%7C29b1d360ac174983f94f08d8a72690e3%7C72f988bf86f141af91ab2d7cd
|  > >
|  011db47%7C1%7C0%7C637443131387709733%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
|  > >
|  iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
|  > >
|  mp;sdata=khBFDraMl63ohsoPPc%2BObNIQTjcaYJ3Q2ER1XbT%2BWpw%3D&amp;rese
|  > > rved=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&amp;data=04%7
|  >
|  C01%7Csimonpj%40microsoft.com%7C29b1d360ac174983f94f08d8a72690e3%7C72f
|  >
|  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637443131387709733%7CUnknown%7
|  >
|  CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
|  >
|  CI6Mn0%3D%7C1000&amp;sdata=a9NLr7lAzgHZ4B2xH02nSOPB6nFxcdSbJh9Bp0d7Z3s
|  > %3D&amp;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%2F
|  > 0000-
|  ghc2021.rst%23data&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C2
|  >
|  9b1d360ac174983f94f08d8a72690e3%7C72f988bf86f141af91ab2d7cd011db47%7C1
|  >
|  %7C0%7C637443131387709733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
|  >
|  LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2xLfaK
|  > WXqXJRy5gRGmiVxTTDN%2Ftw0zqAt%2Bk3B6QuSBE%3D&amp;reserved=0
|  
|  
|  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.
|  gitlab.haskell.org%2Fghc%2Fdoc%2Fusers_guide%2Fexts.html&amp;data=04%7
|  C01%7Csimonpj%40microsoft.com%7C29b1d360ac174983f94f08d8a72690e3%7C72f
|  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637443131387709733%7CUnknown%7
|  CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
|  CI6Mn0%3D%7C1000&amp;sdata=a9NLr7lAzgHZ4B2xH02nSOPB6nFxcdSbJh9Bp0d7Z3s
|  %3D&amp;reserved=0
|  
|  From this I produce the output at
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-ghc2021.rst%23executive-
|  summary&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C29b1d360ac174983f
|  94f08d8a72690e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637443131
|  387709733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
|  LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RQ%2Fhd3Ht1qj%2BY%2F%2
|  FSYflrz6tYeuUHJvt1cYYlfEMnlFg%3D&amp;reserved=0
|  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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C29b1d360ac
|  174983f94f08d8a72690e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7443131387709733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oUrkJc1jliIfxOL
|  O3t6tAq2U8H2mXbHmg5ruinyF%2B8Y%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C29b1d360ac17498
|  3f94f08d8a72690e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374431
|  31387719726%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=o798%2BRqlA6nRJ4eKLd
|  %2Fljyz8tcBtfAdLAgMzd986Cj8%3D&amp;reserved=0

From mail at joachim-breitner.de  Wed Dec 23 11:14:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 23 Dec 2020 12:14:59 +0100
Subject: [ghc-steering-committee] #380 GHC2021: Structured summary
In-Reply-To: <VI1PR83MB022252776A8CB3ADE8EB3F70ADDE9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <eca375433d1e064b1d15250e94ed75a97d4432c0.camel@joachim-breitner.de>
 <VI1PR83MB0222BECB56BB542DA367E61AADC09@VI1PR83MB0222.EURPRD83.prod.outlook.com>
 <602220b62cf41629fddeac648bde36fff290767d.camel@joachim-breitner.de>
 <183fc007270be58116118f2d6abcf4402336e6f2.camel@joachim-breitner.de>
 <VI1PR83MB022252776A8CB3ADE8EB3F70ADDE9@VI1PR83MB0222.EURPRD83.prod.outlook.com>
Message-ID: <9f0de4df03f9512ecef9d15c6923d257faf15bdf.camel@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#extension-DeriveGeneric
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-ForeignFunctionInterface
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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Thu Dec 24 14:25:40 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 24 Dec 2020 15:25:40 +0100
Subject: [ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
Message-ID: <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>

Hi,

mostly a technical point, but just to avoid confusion

MonadFailDesugaring is already on by default, and according to the
docs, is supposed to be deprecated, _but making that behaviour
permanent_. (So, really, NoMonadFailDesugaring is what is being
deprecated).

I was previously confused by this and voted for “no”, which is not what
my intention is.  I updated my vote to “yes”.

This now has 7 votes and reached “barely out” status.

Dear Richard and Simon, Simon, Tom:
You currently have “maybe”, “irrelevant” or “no” here. Do you indeed
want to deviate from the documented plan of getting rid of
NoMonadFailDesugaring?

Cheers,
Joachim



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



From rae at richarde.dev  Thu Dec 24 18:52:28 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 24 Dec 2020 18:52:28 +0000
Subject: [ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
In-Reply-To: <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
Message-ID: <010f017696185de1-8d796e18-8dbf-447d-a2eb-6c719350390c-000000@us-east-2.amazonses.com>



> On Dec 24, 2020, at 9:25 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Richard and Simon, Simon, Tom:
> You currently have “maybe”, “irrelevant” or “no” here. Do you indeed
> want to deviate from the documented plan of getting rid of
> NoMonadFailDesugaring?

No, I don't. Please change my vote to "yes". Or do you need a new full slate for that to happen?

Thanks!
Richard

> 
> Cheers,
> Joachim
> 
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Fri Dec 25 11:26:56 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 25 Dec 2020 12:26:56 +0100
Subject: [ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
In-Reply-To: <010f017696185de1-8d796e18-8dbf-447d-a2eb-6c719350390c-000000@us-east-2.amazonses.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
 <010f017696185de1-8d796e18-8dbf-447d-a2eb-6c719350390c-000000@us-east-2.amazonses.com>
Message-ID: <e9358d7c770f07a7e78425c62155b74f4ee40d29.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 24.12.2020, 18:52 +0000 schrieb Richard Eisenberg:
> > On Dec 24, 2020, at 9:25 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Dear Richard and Simon, Simon, Tom:
> > You currently have “maybe”, “irrelevant” or “no” here. Do you indeed
> > want to deviate from the documented plan of getting rid of
> > NoMonadFailDesugaring?
> 
> No, I don't. Please change my vote to "yes". Or do you need a new
> full slate for that to happen?
> 

not needed, the ballot tallying system involves a (possibly artificial,
will not tell) intelligence.

Noted. (MonadFailDesugaring now in “barely in” category, so all izz
well.)

Cheers,
Joachim

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



From simonpj at microsoft.com  Mon Dec 28 09:52:05 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 28 Dec 2020 09:52:05 +0000
Subject: [ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
In-Reply-To: <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB02220FF2FD6BE080C0BCA353ADD99@VI1PR83MB0222.EURPRD83.prod.outlook.com>

The user manual is pretty confusing. 
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/monadfail_desugaring.html?highlight=monadfaildesugar#extension-MonadFailDesugaring

It says
* The extension is enabled by default
* The extension is temporary and will be deprecated in future

Those two seem to contradict.

Let's check.  I believe that, 
* Today, by default, MonadFailDesugaring is on; 
  that is, we desugar do-blocks to use MonadFail.fail
* That behaviour is what we want, permanently
* The extension -XMonadFailDesugaring and -XNoMonadFailDesugaring
  are already deprecated, but have not yet been removed.
* When we remove them, we'll continue to desugar do-blocks to us
  MonadFail.fail

We were due to remove them in 8.8, as the proposal says under "Transitional Strategy"
https://gitlab.haskell.org/haskell/prime/-/wikis/libraries/proposals/monad-fail

But we failed to do so.

I conclude: we don't need votes on this.  We should just execute on the proposal and remove the flags.  

I see that the proposal lists the following steps for GHC 8.2:
1. Remove -XMonadFail leaving its effects on at all times.
2. Remove fail from Monad
3. Instead, re-export Control.Monad.Fail.fail as Prelude.fail 
   and Control.Monad.fail
4. Control.Monad.Fail is now a redundant module that can be 
   considered deprecated.

We appear to have done (2) and (3), but not (1) or (4).  Would someone like to make a ticket to do them?

Thanks

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 24 December 2020 14:26
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] #380 GHC2021:
|  MonadFailDesugaring
|  
|  Hi,
|  
|  mostly a technical point, but just to avoid confusion
|  
|  MonadFailDesugaring is already on by default, and according to the
|  docs, is supposed to be deprecated, _but making that behaviour
|  permanent_. (So, really, NoMonadFailDesugaring is what is being
|  deprecated).
|  
|  I was previously confused by this and voted for "no", which is not
|  what my intention is.  I updated my vote to "yes".
|  
|  This now has 7 votes and reached "barely out" status.
|  
|  Dear Richard and Simon, Simon, Tom:
|  You currently have "maybe", "irrelevant" or "no" here. Do you indeed
|  want to deviate from the documented plan of getting rid of
|  NoMonadFailDesugaring?
|  
|  Cheers,
|  Joachim
|  
|  
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C6ae8267910
|  27460892dd08d8a817d464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7444167613589334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=xYsdNqG4kjNBVYv
|  N1vMK8Uny90nOwCBjrCA%2BDiojq%2Bg%3D&amp;reserved=0
|  
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C6ae826791027460
|  892dd08d8a817d464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374441
|  67613589334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YKF4XyWy8j8KF3xMQMQt
|  VBYL977cbSWRaLsnqtrj55M%3D&amp;reserved=0

From marlowsd at gmail.com  Thu Dec 31 11:35:58 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 31 Dec 2020 11:35:58 +0000
Subject: [ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
In-Reply-To: <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <5bfcc4eefd8eb7199adbdd0274fdf17d9348248d.camel@joachim-breitner.de>
Message-ID: <CANsrgPKUpLrOJDdfoOQXKkv0ZXagbUobVbztupYQfR06Ta2xFQ@mail.gmail.com>

I don't think MonadFailDesugaring should have been part of the GHC2021
discussion at all - it's part of an existing migration plan, and there's no
reason to disrupt that with GHC2021. That's why I labeled it "irrelevant"
in my vote.

Cheers
Simon

On Thu, 24 Dec 2020 at 14:25, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> mostly a technical point, but just to avoid confusion
>
> MonadFailDesugaring is already on by default, and according to the
> docs, is supposed to be deprecated, _but making that behaviour
> permanent_. (So, really, NoMonadFailDesugaring is what is being
> deprecated).
>
> I was previously confused by this and voted for “no”, which is not what
> my intention is.  I updated my vote to “yes”.
>
> This now has 7 votes and reached “barely out” status.
>
> Dear Richard and Simon, Simon, Tom:
> You currently have “maybe”, “irrelevant” or “no” here. Do you indeed
> want to deviate from the documented plan of getting rid of
> NoMonadFailDesugaring?
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201231/bdfbca94/attachment.html>

From marlowsd at gmail.com  Thu Dec 31 12:01:21 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 31 Dec 2020 12:01:21 +0000
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <1d2494f5-10ff-403a-aa7d-5758f604c26a@www.fastmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
 <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>
 <1d2494f5-10ff-403a-aa7d-5758f604c26a@www.fastmail.com>
Message-ID: <CANsrgP+eDWTzAZ7hjfxWuix-_xySb8fA0mWiVVE5Q7KDNSXXNg@mail.gmail.com>

On Fri, 18 Dec 2020 at 16:44, Eric Seidel <eric at seidel.io> wrote:

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

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. That said, we do have
quite a few notable exceptions currently, e.g. CPP, TemplateHaskell,
PackageImports, Safe, and a few more. We could reasonably consider these to
be special cases, though.

Cheers
Simon

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201231/6a555688/attachment.html>

From eric at seidel.io  Thu Dec 31 15:20:30 2020
From: eric at seidel.io (Eric Seidel)
Date: Thu, 31 Dec 2020 09:20:30 -0600
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <CANsrgP+eDWTzAZ7hjfxWuix-_xySb8fA0mWiVVE5Q7KDNSXXNg@mail.gmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
 <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>
 <1d2494f5-10ff-403a-aa7d-5758f604c26a@www.fastmail.com>
 <CANsrgP+eDWTzAZ7hjfxWuix-_xySb8fA0mWiVVE5Q7KDNSXXNg@mail.gmail.com>
Message-ID: <862072c9-291d-4de2-b24a-7c05a05ba50c@www.fastmail.com>

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

From mail at joachim-breitner.de  Thu Dec 31 15:26:09 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 31 Dec 2020 16:26:09 +0100
Subject: [ghc-steering-committee] A plea for ForeignFunctionInterface
In-Reply-To: <862072c9-291d-4de2-b24a-7c05a05ba50c@www.fastmail.com>
References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de>
 <a1e57fd18840ee40583668d35f0968f284894264.camel@joachim-breitner.de>
 <CANsrgPLpEmhMMVQuuvasHaqBmbGnLDAFTZcY+23fgWATwukA6A@mail.gmail.com>
 <CAF3RzK_5ZHeZDc9MXYN7-PkJvYpRBdTqgU=9iRNqZi5bs__H+w@mail.gmail.com>
 <B37EB44A-E2D4-4930-8305-4929C2866F6B@seidel.io>
 <CANsrgP+wr74KGC=mgs6meVZFnrpnNn+9iXROgDmrCGfcJMpHpw@mail.gmail.com>
 <1d2494f5-10ff-403a-aa7d-5758f604c26a@www.fastmail.com>
 <CANsrgP+eDWTzAZ7hjfxWuix-_xySb8fA0mWiVVE5Q7KDNSXXNg@mail.gmail.com>
 <862072c9-291d-4de2-b24a-7c05a05ba50c@www.fastmail.com>
Message-ID: <38fb59dd697816264a7d0f8270a69ef64afeb731.camel@joachim-breitner.de>

Am Donnerstag, den 31.12.2020, 09:20 -0600 schrieb Eric Seidel:
> Joachim, can you change my vote for FFI to "yes"? I think it's already in,
> but that should make it safely in.

✓


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