From iavor.diatchki at gmail.com  Tue Sep  1 16:18:49 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 1 Sep 2020 09:18:49 -0700
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>

Thanks for doing this Richard.   I wonder if there might be a different way
to organize this, that is more suitable for discussion?   I just had a look
at the page, and here are some issue I felt:
   - The page is already very long, and it barely has any comments.   I
wonder if it might make sense to have one page per extension, instead?  Or
at least a separate page for a group of related extensions?
   - Having a discussion on the wiki is tricky, and maybe before we do that
and involve the rest of the community, we could practice among ourselves,
at least until we figure out, for example, what might be suitable criteria
   - When I evaluate the extensions, I do apply some criterias, but my
decisions are often not as binary as "this fits" or "this not", but rather
more along the lines of "this would make this a little better", "while this
might make things a little worse", and "if this was on, I might have to
watch out for X,Y,Z, is that a problem?".   I am not sure how to capture
this though.

So, I think my preference would be to have some discussion on the mailing
list, or maybe we could even have a video chat with interested folks on
specific topics, rather than trying to do everything on the wiki straight
away...

-Iavor
PS:  By the way, the FFI is part of Haskell2020,  but on the wiki Richard
marked it as not qualifying under his criteria 5.  I would expect GHC 202X
to be a super-set of the language standard, or do you think we should be
also removing things?






On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg <rae at richarde.dev> wrote:

> A fun way to start the fall. (Today is my daughter's first day of
> "school". This defines the beginning of fall.) Thanks, Iavor, for kicking
> this off.
>
> I initially wrote a long email in this space, with numbered criteria
> (heavily based on Iavor's suggestions) and my thoughts on the individual
> extensions proposed. But I realized this would quickly grow unwieldy. I
> thus have created
> https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I
> propose we track this conversation. Specifically: arguments for or against
> an individual extension should go right on the wiki, labeled with the
> author's name/initials. This preserves these arguments for later. Then, to
> keep the conversation moving, write back to this list just mentioning which
> extensions you've commented on.
>
> Please review the criteria on the wiki page. Do you agree with what I've
> put forward?
>
> I've commented on the following extensions:
>
> ApplicativeDo
> CApiFFI
> EmptyCase
> ExplicitNamespaces
> ForeignFunctionInterface
> LambdaCase
> MultiWayIf
> NamedFieldPuns
> OverloadedLists
> OverloadedStrings
> PatternSynonyms
> RecordWildCards
> ScopedTypeVariables
> StandaloneKindSignatures
> TupleSections
> TypeOperators
>
> I have added these new extensions for consideration:
>
> MultiParamTypeClasses
> ImplicitParams
> FlexibleContexts
> FlexibleInstances
> GeneralizedNewtypeDeriving
> DeriveDataTypeable
> DeriveGeneric
> DefaultSignatures
> InstanceSigs
> ConstrainedClassMethods
> ExplicitForAll
> DeriveFunctor
> DeriveTraversable
> DeriveFoldable
> PolyKinds
> RoleAnnotations
> NegativeLiterals
> DeriveAnyClass
> DeriveLift
> DerivingStrategies
> EmptyDataDeriving
>
> Looking forward to seeing your thoughts here!
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200901/1eeda48f/attachment.html>

From eric at seidel.io  Tue Sep  1 16:52:44 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 01 Sep 2020 12:52:44 -0400
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
Message-ID: <21cdafa4-32e5-451d-afab-8c63e6368e2c@www.fastmail.com>

On Tue, Sep 1, 2020, at 12:18, Iavor Diatchki wrote:

> PS:  By the way, the FFI is part of Haskell2020,  but on the wiki 
> Richard marked it as not qualifying under his criteria 5.  I would 
> expect GHC 202X to be a super-set of the language standard, or do you 
> think we should be also removing things?

Actually, it's even part of Haskell2010[1], and GHC does enable it by default today. I thought we would be changing the default by adding it to GHC2020, but since we aren't I'm less concerned about FFI.

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008

From rae at richarde.dev  Tue Sep  1 18:27:42 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 1 Sep 2020 18:27:42 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
Message-ID: <010f01744aecbb05-c9e7008c-ea79-4658-80d9-73f3b164ff85-000000@us-east-2.amazonses.com>



> On Sep 1, 2020, at 12:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Thanks for doing this Richard.   I wonder if there might be a different way to organize this, that is more suitable for discussion? 

I agree that the wiki page isn't ideal -- but I don't have a better suggestion, short of, say, a different ticket for each extension (or set of related extensions). My big worry is that email is terrible at this sort of thing. Either everyone quotes every prior person's entire message, or we quote selectively and then easily lose history. Gathering the set of comments pertinent to one extension will be manual and painful.
> 
>    - When I evaluate the extensions, I do apply some criterias, but my decisions are often not as binary as "this fits" or "this not", but rather more along the lines of "this would make this a little better", "while this might make things a little worse", and "if this was on, I might have to watch out for X,Y,Z, is that a problem?".   I am not sure how to capture this though.

I tend to agree here, both on the evaluation and unsureness of how to capture.

> 
> So, I think my preference would be to have some discussion on the mailing list, or maybe we could even have a video chat with interested folks on specific topics, rather than trying to do everything on the wiki straight away...

As I said above, I think email is a poor place to do this, because we will end up having to pore through the email chain to recreate decisions/rationale for each extension. The wiki is in my opinion a less-poor place to do this. Maybe there is a good place to have the discussion -- that would be great.

> 
> -Iavor
> PS:  By the way, the FFI is part of Haskell2020,  but on the wiki Richard marked it as not qualifying under his criteria 5.  I would expect GHC 202X to be a super-set of the language standard, or do you think we should be also removing things?

I was reacting to Eric's concern about FFI. I've updated the wiki to say that FFI is part of Haskell2010. I agree that we should be a superset of extensions.

Richard

> 
> 
> 
> 
> 
> 
> On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> A fun way to start the fall. (Today is my daughter's first day of "school". This defines the beginning of fall.) Thanks, Iavor, for kicking this off.
> 
> I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 <https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020>, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.
> 
> Please review the criteria on the wiki page. Do you agree with what I've put forward?
> 
> I've commented on the following extensions:
> 
> ApplicativeDo
> CApiFFI
> EmptyCase
> ExplicitNamespaces
> ForeignFunctionInterface
> LambdaCase
> MultiWayIf
> NamedFieldPuns
> OverloadedLists
> OverloadedStrings
> PatternSynonyms
> RecordWildCards
> ScopedTypeVariables
> StandaloneKindSignatures
> TupleSections
> TypeOperators
> 
> I have added these new extensions for consideration:
> 
> MultiParamTypeClasses
> ImplicitParams
> FlexibleContexts
> FlexibleInstances
> GeneralizedNewtypeDeriving
> DeriveDataTypeable
> DeriveGeneric
> DefaultSignatures
> InstanceSigs
> ConstrainedClassMethods
> ExplicitForAll
> DeriveFunctor
> DeriveTraversable
> DeriveFoldable
> PolyKinds
> RoleAnnotations
> NegativeLiterals
> DeriveAnyClass
> DeriveLift
> DerivingStrategies
> EmptyDataDeriving
> 
> Looking forward to seeing your thoughts here!
> Richard

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

From mail at joachim-breitner.de  Tue Sep  1 19:14:33 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 Sep 2020 21:14:33 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f01744aecbb05-c9e7008c-ea79-4658-80d9-73f3b164ff85-000000@us-east-2.amazonses.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
 <010f01744aecbb05-c9e7008c-ea79-4658-80d9-73f3b164ff85-000000@us-east-2.amazonses.com>
Message-ID: <461a818c26199277ca48d944be14add3b5ae7d39.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 01.09.2020, 18:27 +0000 schrieb Richard Eisenberg:
> Maybe there is a good place to have the discussion -- that would be great.

I have always wanted to try these websites designed to provide
structure to contentions discussions, in particular 
https://www.kialo.com/tour (it seems it allows private discussions).
Maybe overkill for the endeavor of laying out GHC2020 (which is
hopefully not that contentious once we have rough guidelines), and
maybe not appropriate to use the committee as guinea pigs… OTOH, maybe
it does work better.

Cheers,
Joachim

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



From trupill at gmail.com  Tue Sep  1 19:25:14 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 1 Sep 2020 21:25:14 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f01744aecbb05-c9e7008c-ea79-4658-80d9-73f3b164ff85-000000@us-east-2.amazonses.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
 <010f01744aecbb05-c9e7008c-ea79-4658-80d9-73f3b164ff85-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOu_=VrrGfs8sZFW_xKkWZGuhZfYmhaqJ2-2VRqahBaj3g@mail.gmail.com>

Thanks Richard for organizing the wiki page!

I've added some personal notes, mostly about the fact that I think that
most people expect "ScopedTypeVariables" to be in a new language standard,
even though it breaks some of the rules (which seem like a good general
guidance).

Alejandro

El mar., 1 sept. 2020 a las 20:27, Richard Eisenberg (<rae at richarde.dev>)
escribió:

>
>
> On Sep 1, 2020, at 12:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Thanks for doing this Richard.   I wonder if there might be a different
> way to organize this, that is more suitable for discussion?
>
>
> I agree that the wiki page isn't ideal -- but I don't have a better
> suggestion, short of, say, a different ticket for each extension (or set of
> related extensions). My big worry is that email is terrible at this sort of
> thing. Either everyone quotes every prior person's entire message, or we
> quote selectively and then easily lose history. Gathering the set of
> comments pertinent to one extension will be manual and painful.
>
>
>    - When I evaluate the extensions, I do apply some criterias, but my
> decisions are often not as binary as "this fits" or "this not", but rather
> more along the lines of "this would make this a little better", "while this
> might make things a little worse", and "if this was on, I might have to
> watch out for X,Y,Z, is that a problem?".   I am not sure how to capture
> this though.
>
>
> I tend to agree here, both on the evaluation and unsureness of how to
> capture.
>
>
> So, I think my preference would be to have some discussion on the mailing
> list, or maybe we could even have a video chat with interested folks on
> specific topics, rather than trying to do everything on the wiki straight
> away...
>
>
> As I said above, I think email is a poor place to do this, because we will
> end up having to pore through the email chain to recreate
> decisions/rationale for each extension. The wiki is in my opinion a
> less-poor place to do this. Maybe there is a good place to have the
> discussion -- that would be great.
>
>
> -Iavor
> PS:  By the way, the FFI is part of Haskell2020,  but on the wiki Richard
> marked it as not qualifying under his criteria 5.  I would expect GHC 202X
> to be a super-set of the language standard, or do you think we should be
> also removing things?
>
>
> I was reacting to Eric's concern about FFI. I've updated the wiki to say
> that FFI is part of Haskell2010. I agree that we should be a superset of
> extensions.
>
> Richard
>
>
>
>
>
>
>
> On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> A fun way to start the fall. (Today is my daughter's first day of
>> "school". This defines the beginning of fall.) Thanks, Iavor, for kicking
>> this off.
>>
>> I initially wrote a long email in this space, with numbered criteria
>> (heavily based on Iavor's suggestions) and my thoughts on the individual
>> extensions proposed. But I realized this would quickly grow unwieldy. I
>> thus have created
>> https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I
>> propose we track this conversation. Specifically: arguments for or against
>> an individual extension should go right on the wiki, labeled with the
>> author's name/initials. This preserves these arguments for later. Then, to
>> keep the conversation moving, write back to this list just mentioning which
>> extensions you've commented on.
>>
>> Please review the criteria on the wiki page. Do you agree with what I've
>> put forward?
>>
>> I've commented on the following extensions:
>>
>> ApplicativeDo
>> CApiFFI
>> EmptyCase
>> ExplicitNamespaces
>> ForeignFunctionInterface
>> LambdaCase
>> MultiWayIf
>> NamedFieldPuns
>> OverloadedLists
>> OverloadedStrings
>> PatternSynonyms
>> RecordWildCards
>> ScopedTypeVariables
>> StandaloneKindSignatures
>> TupleSections
>> TypeOperators
>>
>> I have added these new extensions for consideration:
>>
>> MultiParamTypeClasses
>> ImplicitParams
>> FlexibleContexts
>> FlexibleInstances
>> GeneralizedNewtypeDeriving
>> DeriveDataTypeable
>> DeriveGeneric
>> DefaultSignatures
>> InstanceSigs
>> ConstrainedClassMethods
>> ExplicitForAll
>> DeriveFunctor
>> DeriveTraversable
>> DeriveFoldable
>> PolyKinds
>> RoleAnnotations
>> NegativeLiterals
>> DeriveAnyClass
>> DeriveLift
>> DerivingStrategies
>> EmptyDataDeriving
>>
>> Looking forward to seeing your thoughts here!
>> 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/20200901/ca028325/attachment.html>

From eric at seidel.io  Wed Sep  2 04:07:01 2020
From: eric at seidel.io (Eric Seidel)
Date: Wed, 02 Sep 2020 00:07:01 -0400
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
Message-ID: <bdb0adb6-fb8c-436f-a415-3cc552afc2d9@www.fastmail.com>

Github user AntC2 just pointed out that they don't have any way to comment on the discussion that's now happening on the wiki[1]. It turns out that editing privileges are currently restricted to committee members. We could open the floodgates, but, like Iavor, I don't think a wiki will give us the experience we want with many different interested parties.

I think a useful alternative would be to create a new repository in the ghc-proposals org, and use issues to discuss individual extensions. That lets us retain the ease of community involvement that has made the regular proposals process so successful. And it separates extensions into their own discussion threads, which will help us follow the discussion of more controversial extensions. It does mean that we'd have a single, evolving proposal for GHC 2020 instead of the community submitting different fully-formed proposals for us to consider, but I think this is fine given the special nature of GHC 2020, we're not introducing any new functionality that needs specification and consideration of alternative approaches, we're just choosing a coherent set of existing extensions to bundle together into a quasi-standard.

If that sounds like a useful approach, I'm happy to set up the new repository and process.

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/360#issuecomment-685236227

On Tue, Sep 1, 2020, at 12:18, Iavor Diatchki wrote:
> Thanks for doing this Richard.   I wonder if there might be a different 
> way to organize this, that is more suitable for discussion? 

> On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg <rae at richarde.dev> wrote:
> > I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.

From mail at joachim-breitner.de  Wed Sep  2 07:16:04 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 Sep 2020 09:16:04 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <bdb0adb6-fb8c-436f-a415-3cc552afc2d9@www.fastmail.com>
References: <CAGK9nuqJomK58E3c+MoZKh2F36RqbbyxJROwVBvj05PW3WruTQ@mail.gmail.com>
 <010f017445df958a-5e0f4a7c-e31c-4c21-891d-422854d3ec96-000000@us-east-2.amazonses.com>
 <CAGK9nuqxh-h8GwJZRDS06nk+wUx8wUo8h5YEVp7Eot-FdxvmxA@mail.gmail.com>
 <bdb0adb6-fb8c-436f-a415-3cc552afc2d9@www.fastmail.com>
Message-ID: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>

Hi,

sounds plausible. It would also allow us to use tags to easily indicate
the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
then filter by issue to get the current list…

But before we go there, shouldn’t we maybe have a discussion first on

 * do we even want that?
 * what are the abstract criteria (or guidelines)?
 * what is the process?

I believe that discussion could be done like any other proposal.


As for the process; when I brought up the idea, I was worried about us
spending huge resources discussion individual extensions to death, and
proposed, in the interest of efficiency and getting things done:

> The process could be: Every member can nominate any number of 
> extensions, to include, maybe a small rationale and then we do one 
> round of independent approval voting, requiring a supermajority to 
> really only pick uncontested extensions.

So instead of long debates, we start with GHC2020 being just those
extensions that a supermajority on the committee considers to be ok. 

This is much more lightweight process that we could get done in a week
or two (maybe using a doodle-like voting page). Maybe we would leave
out one or two extension that initially people are reserved about, but
could be swayed after lengthy discussions. But is that worth the
lengthy discussion?

cheers,
Joachim

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



From eric at seidel.io  Wed Sep  2 12:11:06 2020
From: eric at seidel.io (Eric Seidel)
Date: Wed, 2 Sep 2020 08:11:06 -0400
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
Message-ID: <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>

Opening a regular discussion about whether and how we want to work on GHC 2020 sounds fine, that will also give the community a place to weigh in. I do think the eventual contents should be informed by the community though, it shouldn’t just be us working alone. 

Sent from my iPhone

> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> sounds plausible. It would also allow us to use tags to easily indicate
> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> then filter by issue to get the current list…
> 
> But before we go there, shouldn’t we maybe have a discussion first on
> 
> * do we even want that?
> * what are the abstract criteria (or guidelines)?
> * what is the process?
> 
> I believe that discussion could be done like any other proposal.
> 
> 
> As for the process; when I brought up the idea, I was worried about us
> spending huge resources discussion individual extensions to death, and
> proposed, in the interest of efficiency and getting things done:
> 
>> The process could be: Every member can nominate any number of 
>> extensions, to include, maybe a small rationale and then we do one 
>> round of independent approval voting, requiring a supermajority to 
>> really only pick uncontested extensions.
> 
> So instead of long debates, we start with GHC2020 being just those
> extensions that a supermajority on the committee considers to be ok. 
> 
> This is much more lightweight process that we could get done in a week
> or two (maybe using a doodle-like voting page). Maybe we would leave
> out one or two extension that initially people are reserved about, but
> could be swayed after lengthy discussions. But is that worth the
> lengthy discussion?
> 
> 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  Wed Sep  2 13:56:50 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Sep 2020 13:56:50 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
 <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
Message-ID: <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>

It seems clear that my wiki idea isn't winning the day -- I never really liked it either. I'd be fine with either Eric's or Joachim's approaches. Maybe start with Joachim's approach and then use Eric's when Joachim's runs out of steam? A big minus, though, to Joachim's approach is that it seems hard to get good community involvement.

Richard

> On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> Opening a regular discussion about whether and how we want to work on GHC 2020 sounds fine, that will also give the community a place to weigh in. I do think the eventual contents should be informed by the community though, it shouldn’t just be us working alone. 
> 
> Sent from my iPhone
> 
>> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi,
>> 
>> sounds plausible. It would also allow us to use tags to easily indicate
>> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
>> then filter by issue to get the current list…
>> 
>> But before we go there, shouldn’t we maybe have a discussion first on
>> 
>> * do we even want that?
>> * what are the abstract criteria (or guidelines)?
>> * what is the process?
>> 
>> I believe that discussion could be done like any other proposal.
>> 
>> 
>> As for the process; when I brought up the idea, I was worried about us
>> spending huge resources discussion individual extensions to death, and
>> proposed, in the interest of efficiency and getting things done:
>> 
>>> The process could be: Every member can nominate any number of 
>>> extensions, to include, maybe a small rationale and then we do one 
>>> round of independent approval voting, requiring a supermajority to 
>>> really only pick uncontested extensions.
>> 
>> So instead of long debates, we start with GHC2020 being just those
>> extensions that a supermajority on the committee considers to be ok. 
>> 
>> This is much more lightweight process that we could get done in a week
>> or two (maybe using a doodle-like voting page). Maybe we would leave
>> out one or two extension that initially people are reserved about, but
>> could be swayed after lengthy discussions. But is that worth the
>> lengthy discussion?
>> 
>> 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 rae at richarde.dev  Thu Sep  3 22:02:17 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Sep 2020 22:02:17 +0000
Subject: [ghc-steering-committee] Proposal #302: `\of`
Message-ID: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>

Hi all,

Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.

PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014

The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:

mplus :: Maybe Int -> Maybe Int -> Maybe Int
mplus = \of
  Nothing _ -> Nothing
  _ Nothing -> Nothing
  (Just x) (Just y) -> Just (x + y)

The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.

I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.

Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.

Richard

From trupill at gmail.com  Fri Sep  4 14:37:09 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Sep 2020 16:37:09 +0200
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>

Hi all,
I agree with the sentiment. I think adding \of would be a nice way to clean
up the language (in the same way that now StandaloneKindSignatures allow us
to remove the weirder CUSKs), but unless we have some deprecation policy
for extensions, this may confuse people more than help.

It's particularly bad that we cannot make this simply an extension of
\case, due to the example pointed out in the thread: \case Just x -> x.
Could we maybe think of some way to disambiguate those cases? I'm going to
ask this in the thread too.

Regards,
Alejandro

El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> Hi all,
>
> Proposal #302 was submitted to the committee and assigned to Cale. He has
> made a recommendation on the GitHub trail, but I don't believe the
> committee has discussed this among ourselves.
>
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
> Proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
> Cale's recommendation:
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>
> The idea, in brief, is to introduce a new syntax (guarded behind
> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>
> mplus :: Maybe Int -> Maybe Int -> Maybe Int
> mplus = \of
>   Nothing _ -> Nothing
>   _ Nothing -> Nothing
>   (Just x) (Just y) -> Just (x + y)
>
> The new keyword allows us to use a syntax similar to function definitions,
> but without repeating the name of the function. It is also like \case, but
> it allows multiple arguments. Guards are allowed, as usual.
>
> I really like this new syntax -- mostly because I find it very strange
> that we have to repeat the function name on every line. And then change the
> spacing when we change the function name. And I like the mnemonic "lambda
> of". And it allows me to write a where clause that is accessible in
> multiple different patterns, or an indented where clause that is usable in
> just one. If it didn't confuse readers, I would use this syntax all the
> time.
>
> Even so, I agree with Cale's recommendation to reject. We just have too
> much syntax! If someone were to come along and draft a concrete proposal of
> how we could, for example, use this syntax to replace both \case and if|,
> with a migration strategy, etc., then I might be in favor. Until then, I
> think we've spent our budget for cute, obscure bits of syntax.
>
> 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/20200904/83e42942/attachment.html>

From rae at richarde.dev  Fri Sep  4 14:55:00 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 4 Sep 2020 14:55:00 +0000
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>
Message-ID: <010f0174599d139f-97b92a93-9d9f-4f21-89ed-dcdae14c6ba9-000000@us-east-2.amazonses.com>

Thinking about disambiguating \case Just x -> x: There is no way that \of Just x -> ... can be correct, because Just requires an argument. Very happily, the renamer's behavior is unaffected: any variables introduced are still binding sites. So, I think we could probably detect a case like this in the type-checker and either reinterpret it correct or provide a very helpful error message.

So here's a concrete idea:

- Change the existing proposal to use \case instead of \of.
- Add a little magic to the type-checker, as specified below, to allow current usages of \case to be accepted.
- When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on by default).
- Remove the magic (and its warning) in a few releases.

The magic:
- The new construct allows many patterns before the -> where the old \case allowed only one.
- The type-checker detects when the first of these patterns is a solitary constructor, and when this constructor is not nullary.
- It then reconstructs the AST to move the remaining patterns as arguments of that first one. Because our AST tracks parens manually, the new AST will even print identically to the old one.

This magic is, well, magical, but it's well specified, backward compatible, and unambiguous.

What do we think?

Richard

> On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Hi all,
> I agree with the sentiment. I think adding \of would be a nice way to clean up the language (in the same way that now StandaloneKindSignatures allow us to remove the weirder CUSKs), but unless we have some deprecation policy for extensions, this may confuse people more than help.
> 
> It's particularly bad that we cannot make this simply an extension of \case, due to the example pointed out in the thread: \case Just x -> x. Could we maybe think of some way to disambiguate those cases? I'm going to ask this in the thread too.
> 
> Regards,
> Alejandro
> 
> El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev <mailto:rae at richarde.dev>>) escribió:
> Hi all,
> 
> Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.
> 
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 <https://github.com/ghc-proposals/ghc-proposals/pull/302>
> Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md <https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md>
> Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014 <https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014>
> 
> The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:
> 
> mplus :: Maybe Int -> Maybe Int -> Maybe Int
> mplus = \of
>   Nothing _ -> Nothing
>   _ Nothing -> Nothing
>   (Just x) (Just y) -> Just (x + y)
> 
> The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.
> 
> I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.
> 
> Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.
> 
> Richard
> _______________________________________________
> 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/20200904/c9d42929/attachment.html>

From trupill at gmail.com  Fri Sep  4 14:57:00 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 4 Sep 2020 16:57:00 +0200
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <010f0174599d139f-97b92a93-9d9f-4f21-89ed-dcdae14c6ba9-000000@us-east-2.amazonses.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>
 <010f0174599d139f-97b92a93-9d9f-4f21-89ed-dcdae14c6ba9-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtOwnW_OycxCyURssqdgnDDtMDHMOw2oOzzayQk6hD+nw@mail.gmail.com>

I think that would work pretty well. In fact, the implementation of such a
rule would allow us to also point beginners when they need parentheses in
regular pattern matching!

El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> Thinking about disambiguating \case Just x -> x: There is no way that \of
> Just x -> ... can be correct, because Just requires an argument. Very
> happily, the renamer's behavior is unaffected: any variables introduced are
> still binding sites. So, I think we could probably detect a case like this
> in the type-checker and either reinterpret it correct or provide a very
> helpful error message.
>
> So here's a concrete idea:
>
> - Change the existing proposal to use \case instead of \of.
> - Add a little magic to the type-checker, as specified below, to allow
> current usages of \case to be accepted.
> - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on
> by default).
> - Remove the magic (and its warning) in a few releases.
>
> The magic:
> - The new construct allows many patterns before the -> where the old \case
> allowed only one.
> - The type-checker detects when the first of these patterns is a solitary
> constructor, and when this constructor is not nullary.
> - It then reconstructs the AST to move the remaining patterns as arguments
> of that first one. Because our AST tracks parens manually, the new AST will
> even print identically to the old one.
>
> This magic is, well, magical, but it's well specified, backward
> compatible, and unambiguous.
>
> What do we think?
>
> Richard
>
> On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> Hi all,
> I agree with the sentiment. I think adding \of would be a nice way to
> clean up the language (in the same way that now StandaloneKindSignatures
> allow us to remove the weirder CUSKs), but unless we have some deprecation
> policy for extensions, this may confuse people more than help.
>
> It's particularly bad that we cannot make this simply an extension of
> \case, due to the example pointed out in the thread: \case Just x -> x.
> Could we maybe think of some way to disambiguate those cases? I'm going to
> ask this in the thread too.
>
> Regards,
> Alejandro
>
> El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
>> Hi all,
>>
>> Proposal #302 was submitted to the committee and assigned to Cale. He has
>> made a recommendation on the GitHub trail, but I don't believe the
>> committee has discussed this among ourselves.
>>
>> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
>> Proposal:
>> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
>> Cale's recommendation:
>> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>>
>> The idea, in brief, is to introduce a new syntax (guarded behind
>> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>>
>> mplus :: Maybe Int -> Maybe Int -> Maybe Int
>> mplus = \of
>>   Nothing _ -> Nothing
>>   _ Nothing -> Nothing
>>   (Just x) (Just y) -> Just (x + y)
>>
>> The new keyword allows us to use a syntax similar to function
>> definitions, but without repeating the name of the function. It is also
>> like \case, but it allows multiple arguments. Guards are allowed, as usual.
>>
>> I really like this new syntax -- mostly because I find it very strange
>> that we have to repeat the function name on every line. And then change the
>> spacing when we change the function name. And I like the mnemonic "lambda
>> of". And it allows me to write a where clause that is accessible in
>> multiple different patterns, or an indented where clause that is usable in
>> just one. If it didn't confuse readers, I would use this syntax all the
>> time.
>>
>> Even so, I agree with Cale's recommendation to reject. We just have too
>> much syntax! If someone were to come along and draft a concrete proposal of
>> how we could, for example, use this syntax to replace both \case and if|,
>> with a migration strategy, etc., then I might be in favor. Until then, I
>> think we've spent our budget for cute, obscure bits of syntax.
>>
>> 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/20200904/add9b441/attachment-0001.html>

From iavor.diatchki at gmail.com  Fri Sep  4 16:04:00 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Sep 2020 09:04:00 -0700
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <CAHnFXOtOwnW_OycxCyURssqdgnDDtMDHMOw2oOzzayQk6hD+nw@mail.gmail.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>
 <010f0174599d139f-97b92a93-9d9f-4f21-89ed-dcdae14c6ba9-000000@us-east-2.amazonses.com>
 <CAHnFXOtOwnW_OycxCyURssqdgnDDtMDHMOw2oOzzayQk6hD+nw@mail.gmail.com>
Message-ID: <CAGK9nurkZr0NJTexjhxY-sH9QDa34ZPXVhvXQfawVb97+w=rNg@mail.gmail.com>

I am not sure what problem we are solving, and I doubt this would lead to
more readable Haskell, or more streamlined language definition.  So what's
the gain?


On Fri, Sep 4, 2020 at 7:57 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I think that would work pretty well. In fact, the implementation of such a
> rule would allow us to also point beginners when they need parentheses in
> regular pattern matching!
>
> El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
>> Thinking about disambiguating \case Just x -> x: There is no way that \of
>> Just x -> ... can be correct, because Just requires an argument. Very
>> happily, the renamer's behavior is unaffected: any variables introduced are
>> still binding sites. So, I think we could probably detect a case like this
>> in the type-checker and either reinterpret it correct or provide a very
>> helpful error message.
>>
>> So here's a concrete idea:
>>
>> - Change the existing proposal to use \case instead of \of.
>> - Add a little magic to the type-checker, as specified below, to allow
>> current usages of \case to be accepted.
>> - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on
>> by default).
>> - Remove the magic (and its warning) in a few releases.
>>
>> The magic:
>> - The new construct allows many patterns before the -> where the old
>> \case allowed only one.
>> - The type-checker detects when the first of these patterns is a solitary
>> constructor, and when this constructor is not nullary.
>> - It then reconstructs the AST to move the remaining patterns as
>> arguments of that first one. Because our AST tracks parens manually, the
>> new AST will even print identically to the old one.
>>
>> This magic is, well, magical, but it's well specified, backward
>> compatible, and unambiguous.
>>
>> What do we think?
>>
>> Richard
>>
>> On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Hi all,
>> I agree with the sentiment. I think adding \of would be a nice way to
>> clean up the language (in the same way that now StandaloneKindSignatures
>> allow us to remove the weirder CUSKs), but unless we have some deprecation
>> policy for extensions, this may confuse people more than help.
>>
>> It's particularly bad that we cannot make this simply an extension of
>> \case, due to the example pointed out in the thread: \case Just x -> x.
>> Could we maybe think of some way to disambiguate those cases? I'm going to
>> ask this in the thread too.
>>
>> Regards,
>> Alejandro
>>
>> El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev>)
>> escribió:
>>
>>> Hi all,
>>>
>>> Proposal #302 was submitted to the committee and assigned to Cale. He
>>> has made a recommendation on the GitHub trail, but I don't believe the
>>> committee has discussed this among ourselves.
>>>
>>> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
>>> Proposal:
>>> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
>>> Cale's recommendation:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>>>
>>> The idea, in brief, is to introduce a new syntax (guarded behind
>>> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>>>
>>> mplus :: Maybe Int -> Maybe Int -> Maybe Int
>>> mplus = \of
>>>   Nothing _ -> Nothing
>>>   _ Nothing -> Nothing
>>>   (Just x) (Just y) -> Just (x + y)
>>>
>>> The new keyword allows us to use a syntax similar to function
>>> definitions, but without repeating the name of the function. It is also
>>> like \case, but it allows multiple arguments. Guards are allowed, as usual.
>>>
>>> I really like this new syntax -- mostly because I find it very strange
>>> that we have to repeat the function name on every line. And then change the
>>> spacing when we change the function name. And I like the mnemonic "lambda
>>> of". And it allows me to write a where clause that is accessible in
>>> multiple different patterns, or an indented where clause that is usable in
>>> just one. If it didn't confuse readers, I would use this syntax all the
>>> time.
>>>
>>> Even so, I agree with Cale's recommendation to reject. We just have too
>>> much syntax! If someone were to come along and draft a concrete proposal of
>>> how we could, for example, use this syntax to replace both \case and if|,
>>> with a migration strategy, etc., then I might be in favor. Until then, I
>>> think we've spent our budget for cute, obscure bits of syntax.
>>>
>>> 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/20200904/6dd97f62/attachment.html>

From arnaud.spiwack at tweag.io  Mon Sep  7 06:21:15 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 7 Sep 2020 08:21:15 +0200
Subject: [ghc-steering-committee] Attempt at clarifying the template
	language
In-Reply-To: <CAH6fHQno05GaCVZ0fX4tytSX0u-YREbaKvJf9rtaO7oGRNv+hw@mail.gmail.com>
References: <CAH6fHQno05GaCVZ0fX4tytSX0u-YREbaKvJf9rtaO7oGRNv+hw@mail.gmail.com>
Message-ID: <CAH6fHQkjDfy+eWwdm=m05yTib6uwj9Sjeg8QT8TkzT5caeNnjQ@mail.gmail.com>

Dear all,

Joachim and Richard are happy with my suggestions. I will merge in a few
days, in case more of us want to have a look before it is merged.

On Fri, Aug 28, 2020 at 2:34 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> I just wrote a short PR[1] which attempts to clarify the language in the
> template. Trying to dispel some confusion that seems to frequently arise as
> to what our expectations are, for proposals. Basically, I tried to announce
> more clearly the things I believe we find ourselves in need to say to
> proposal authors often about the purpose of sections. I probably forgot
> some. So bring in your shepperd experience.
>
> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/358
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200907/2f47147c/attachment.html>

From simonpj at microsoft.com  Mon Sep  7 15:32:16 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Sep 2020 15:32:16 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
 <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
 <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB0429A583C0D8FEC0ECBE94C5AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the
  discussion.  Basically, it's a GHC Proposal, so someone (possibly
  a committee member, possibly not) should write a proposal,
  and we should put it through the process.

* We should advertise the criteria, as Richard has done on the
  wiki page.

* Any such proposal should be informed by data. Notably, extension usage
  in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional
  source of data

* When it comes to the committee, we can (I guess) vote on individual
  extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion.
Maybe it'd work better than GitHub?  Are there other alternatives?
But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Richard Eisenberg
|  Sent: 02 September 2020 14:57
|  To: Eric Seidel <eric at seidel.io>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] GHC 2020
|  
|  It seems clear that my wiki idea isn't winning the day -- I never
|  really liked it either. I'd be fine with either Eric's or Joachim's
|  approaches. Maybe start with Joachim's approach and then use Eric's
|  when Joachim's runs out of steam? A big minus, though, to Joachim's
|  approach is that it seems hard to get good community involvement.
|  
|  Richard
|  
|  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
|  >
|  > Opening a regular discussion about whether and how we want to work on
|  GHC 2020 sounds fine, that will also give the community a place to
|  weigh in. I do think the eventual contents should be informed by the
|  community though, it shouldn’t just be us working alone.
|  >
|  > Sent from my iPhone
|  >
|  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
|  breitner.de> wrote:
|  >>
|  >> Hi,
|  >>
|  >> sounds plausible. It would also allow us to use tags to easily
|  indicate
|  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
|  >> then filter by issue to get the current list…
|  >>
|  >> But before we go there, shouldn’t we maybe have a discussion first
|  on
|  >>
|  >> * do we even want that?
|  >> * what are the abstract criteria (or guidelines)?
|  >> * what is the process?
|  >>
|  >> I believe that discussion could be done like any other proposal.
|  >>
|  >>
|  >> As for the process; when I brought up the idea, I was worried about
|  us
|  >> spending huge resources discussion individual extensions to death,
|  and
|  >> proposed, in the interest of efficiency and getting things done:
|  >>
|  >>> The process could be: Every member can nominate any number of
|  >>> extensions, to include, maybe a small rationale and then we do one
|  >>> round of independent approval voting, requiring a supermajority to
|  >>> really only pick uncontested extensions.
|  >>
|  >> So instead of long debates, we start with GHC2020 being just those
|  >> extensions that a supermajority on the committee considers to be ok.
|  >>
|  >> This is much more lightweight process that we could get done in a
|  week
|  >> or two (maybe using a doodle-like voting page). Maybe we would leave
|  >> out one or two extension that initially people are reserved about,
|  but
|  >> could be swayed after lengthy discussions. But is that worth the
|  >> lengthy discussion?
|  >>
|  >> cheers,
|  >> Joachim
|  >>
|  >> --
|  >> Joachim Breitner
|  >> mail at joachim-breitner.de
|  >>
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
|  achim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf
|  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0

From trupill at gmail.com  Tue Sep  8 08:13:04 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 8 Sep 2020 10:13:04 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB0429A583C0D8FEC0ECBE94C5AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
 <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
 <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>
 <VI1PR83MB0429A583C0D8FEC0ECBE94C5AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOvNN-37eT5qizRU=5OpNHM5ttXMhfpsc+C-MknrTpo1kQ@mail.gmail.com>

Dear all,
I would really like to move this forward, and I would be happy to put some
work on it.

What do you think of the following plan?
- Create a ghc-proposal based on the (awesome) wiki page by Richard. I
think the criteria in the wiki are quite nice. Explain that one of the
goals is to encompass as many stable extensions as possible.
- Reformat the list to make 3 tables: one for extensions which satisfy all
5 criteria, one for extensions we want to include even if they don't, and
one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a
yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,
Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:

> Just back from holiday. Some thoughts
>
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
>
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
>
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>
> * A proposer might also want to run a public poll, as an additional
>   source of data
>
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
>
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |
> |  Richard
> |
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> cheers,
> |  >> Joachim
> |  >>
> |  >> --
> |  >> Joachim Breitner
> |  >> mail at joachim-breitner.de
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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/20200908/6cadb641/attachment-0001.html>

From simonpj at microsoft.com  Tue Sep  8 10:37:48 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Sep 2020 10:37:48 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOvNN-37eT5qizRU=5OpNHM5ttXMhfpsc+C-MknrTpo1kQ@mail.gmail.com>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
 <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
 <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>
 <VI1PR83MB0429A583C0D8FEC0ECBE94C5AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvNN-37eT5qizRU=5OpNHM5ttXMhfpsc+C-MknrTpo1kQ@mail.gmail.com>
Message-ID: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should

  *   establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
  *   express open-ness to a proposal, and then
  *   review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible.

What do others think?

Simon

From: Alejandro Serrano Mena <trupill at gmail.com>
Sent: 08 September 2020 09:13
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,
I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?
- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,
Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>) escribió:
Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the
  discussion.  Basically, it's a GHC Proposal, so someone (possibly
  a committee member, possibly not) should write a proposal,
  and we should put it through the process.

* We should advertise the criteria, as Richard has done on the
  wiki page.

* Any such proposal should be informed by data. Notably, extension usage
  in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional
  source of data

* When it comes to the committee, we can (I guess) vote on individual
  extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion.
Maybe it'd work better than GitHub?  Are there other alternatives?
But that's orthogonal to the GHC 2020 idea; let's not conflate them.

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: 02 September 2020 14:57
|  To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
|  Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  Subject: Re: [ghc-steering-committee] GHC 2020
|
|  It seems clear that my wiki idea isn't winning the day -- I never
|  really liked it either. I'd be fine with either Eric's or Joachim's
|  approaches. Maybe start with Joachim's approach and then use Eric's
|  when Joachim's runs out of steam? A big minus, though, to Joachim's
|  approach is that it seems hard to get good community involvement.
|
|  Richard
|
|  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
|  >
|  > Opening a regular discussion about whether and how we want to work on
|  GHC 2020 sounds fine, that will also give the community a place to
|  weigh in. I do think the eventual contents should be informed by the
|  community though, it shouldn’t just be us working alone.
|  >
|  > Sent from my iPhone
|  >
|  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
|  breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>> wrote:
|  >>
|  >> Hi,
|  >>
|  >> sounds plausible. It would also allow us to use tags to easily
|  indicate
|  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
|  >> then filter by issue to get the current list…
|  >>
|  >> But before we go there, shouldn’t we maybe have a discussion first
|  on
|  >>
|  >> * do we even want that?
|  >> * what are the abstract criteria (or guidelines)?
|  >> * what is the process?
|  >>
|  >> I believe that discussion could be done like any other proposal.
|  >>
|  >>
|  >> As for the process; when I brought up the idea, I was worried about
|  us
|  >> spending huge resources discussion individual extensions to death,
|  and
|  >> proposed, in the interest of efficiency and getting things done:
|  >>
|  >>> The process could be: Every member can nominate any number of
|  >>> extensions, to include, maybe a small rationale and then we do one
|  >>> round of independent approval voting, requiring a supermajority to
|  >>> really only pick uncontested extensions.
|  >>
|  >> So instead of long debates, we start with GHC2020 being just those
|  >> extensions that a supermajority on the committee considers to be ok.
|  >>
|  >> This is much more lightweight process that we could get done in a
|  week
|  >> or two (maybe using a doodle-like voting page). Maybe we would leave
|  >> out one or two extension that initially people are reserved about,
|  but
|  >> could be swayed after lengthy discussions. But is that worth the
|  >> lengthy discussion?
|  >>
|  >> 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.jo
|  achim-
|  breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>%7Cfa6e3a6bcdf
|  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200908/9f700f1d/attachment-0001.html>

From rae at richarde.dev  Tue Sep  8 11:37:54 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 8 Sep 2020 11:37:54 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <35e1948ae9d0fe11c248716d545fc232037ac4a0.camel@joachim-breitner.de>
 <7D1CCB94-D738-4646-A5CE-705835DCC8D3@seidel.io>
 <010f01744f1b1a40-6fe667ca-8be2-493c-aba6-62c8e737f485-000000@us-east-2.amazonses.com>
 <VI1PR83MB0429A583C0D8FEC0ECBE94C5AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvNN-37eT5qizRU=5OpNHM5ttXMhfpsc+C-MknrTpo1kQ@mail.gmail.com>
 <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <010f01746d8210cc-dc6e1ad1-b34b-422e-8dc5-1ca106106761-000000@us-east-2.amazonses.com>

While I don't want to foist more responsibility on the committee, I think it's asking too much of our community to be responsible for this. Invariably, a community member would propose a GHC20XX, there would be lots of debate, the debate would answer some questions and leave others unanswered, and then the committee would vote. During this time, the proposer would have to keep the proposal up to date, based on the hard-to-discern whims of the community, which may end up at odds with the committee (hopefully not too much at odds!). And then the proposal would have to be revised again after the committee votes. This reduces the load on the committee, but it wouldn't make for a rewarding experience for the proposer -- essentially because the person who does the labor (the proposer) wouldn't have very much authority.

I'm fine with Alejandro's plan, and would be fine with trying out a new tool to organize our discussion (or not -- it's all up to the person taking charge). As for responsibility in the future: I don't know if we should codify that updated GHC20XX languages are our responsibility, per se, but they are a function we can perform when we feel the time is right.

Richard



> On Sep 8, 2020, at 6:37 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should
> establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
> express open-ness to a proposal, and then
> review proposals when/if they materialise.
>  
> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible.  
>  
> What do others think?
>  
> Simon
>  
> From: Alejandro Serrano Mena <trupill at gmail.com> 
> Sent: 08 September 2020 09:13
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] GHC 2020
>  
> Dear all,
> 
> I would really like to move this forward, and I would be happy to put some work on it.
> 
>  
> 
> What do you think of the following plan?
> 
> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
> 
> - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.
> 
>  
> 
> If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
> 
>  
> 
> Regards,
> 
> Alejandro
> 
>  
> 
> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>) escribió:
> 
> Just back from holiday. Some thoughts
> 
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
> 
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
> 
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
> 
> * A proposer might also want to run a public poll, as an additional
>   source of data
> 
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
> 
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
> 
> 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: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> |  Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |  
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |  
> |  Richard
> |  
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> 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.jo <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo>
> |  achim-
> |  breitner.de <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>%7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200908/bc792595/attachment-0001.html>

From eric at seidel.io  Tue Sep  8 12:01:04 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 8 Sep 2020 08:01:04 -0400
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. 

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. 

Eric

Sent from my iPhone

>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should
> establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
> express open-ness to a proposal, and then
> review proposals when/if they materialise.
>  
> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. 
>  
> What do others think?
>  
> Simon
>  
> From: Alejandro Serrano Mena <trupill at gmail.com> 
> Sent: 08 September 2020 09:13
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] GHC 2020
>  
> Dear all,
> 
> I would really like to move this forward, and I would be happy to put some work on it.
> 
>  
> 
> What do you think of the following plan?
> 
> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
> 
> - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.
> 
>  
> 
> If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
> 
>  
> 
> Regards,
> 
> Alejandro
> 
>  
> 
> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
> 
> Just back from holiday. Some thoughts
> 
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
> 
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
> 
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
> 
> * A proposer might also want to run a public poll, as an additional
>   source of data
> 
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
> 
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |  
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |  
> |  Richard
> |  
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> cheers,
> |  >> Joachim
> |  >>
> |  >> --
> |  >> Joachim Breitner
> |  >> mail at joachim-breitner.de
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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/20200908/f0fbcff5/attachment-0001.html>

From trupill at gmail.com  Wed Sep  9 10:16:44 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 9 Sep 2020 12:16:44 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
Message-ID: <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>

I would rather make the process Committee-driven, because otherwise it may
derail into too many micro-discussions. I think it's better to start a
conversation saying "this is our proposal, here are our criteria, here are
the exceptions we want to make", and then discuss from there.

Regards,
Alejandro


El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>) escribió:

> I think we may want to have the Committee initiate and drive the process.
> I think a GHC20XX proposal will turn into a bunch of micro proposals and
> discussions about individual (groups of) extensions, and it will be hard to
> track all of the threads of discussion in a single GitHub thread. We’ve
> dealt with long and contentious discussions before, but they were much more
> focused than GHC20XX will be, by design.
>
> I suggested earlier that an alternative strategy could be to open a new
> repo where the community can collaborate on GHC20XX via a familiar PR-based
> process, with each proposed group of extensions getting its own PR and
> discussion. There are a few open questions here though. When/how do we
> decide that it’s time for a new standard? How do we decide when the full
> proposal is ready for review? Do we need to review and sign off on each
> group of extensions separately or only the final product?
>
> This process would be a lot more work for us, so I’m happy to try the
> usual process first, and I’ll be happy to be proved wrong. But we should be
> prepared to step in and add some more structure if needed.
>
> Regardless, the first step should be to update our docs to express
> interest in GHC20XX proposals, establish criteria for including language
> extensions, and outline a process for submitting them.
>
> Eric
>
> Sent from my iPhone
>
> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> 
>
> Personally I don’t think we should make the Steering Committee responsible
> for initiating or driving this.  We should
>
>    - establish the criteria (including some idea of how frequently we’d
>    be open to creating a new GHCxx version),
>    - express open-ness to a proposal, and then
>    - review proposals when/if they materialise.
>
>
>
> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s
> different from making the committee *responsible*.
>
>
>
> What do others think?
>
>
>
> Simon
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 08 September 2020 09:13
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
> ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> Dear all,
>
> I would really like to move this forward, and I would be happy to put some
> work on it.
>
>
>
> What do you think of the following plan?
>
> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
> think the criteria in the wiki are quite nice. Explain that one of the
> goals is to encompass as many stable extensions as possible.
>
> - Reformat the list to make 3 tables: one for extensions which satisfy all
> 5 criteria, one for extensions we want to include even if they don't, and
> one for those which should be rejected in the light of those criteria.
>
>
>
> If the process works well, we could think about instaurating a
> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>
> Just back from holiday. Some thoughts
>
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
>
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
>
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>
> * A proposer might also want to run a public poll, as an additional
>   source of data
>
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
>
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |
> |  Richard
> |
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> cheers,
> |  >> Joachim
> |  >>
> |  >> --
> |  >> Joachim Breitner
> |  >> mail at joachim-breitner.de
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
> %7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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/20200909/6d82d20a/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Sep 10 09:28:22 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 10 Sep 2020 11:28:22 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
Message-ID: <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>

There seems to be some question about who should drive this debate. But
there is something we all seem to agree on: it is our role, as the steering
committee, to announce the criteria by which we intend to judge the
reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this
discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
that they are worthy of discussion. So let me ask the question: do we agree
with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I would rather make the process Committee-driven, because otherwise it may
> derail into too many micro-discussions. I think it's better to start a
> conversation saying "this is our proposal, here are our criteria, here are
> the exceptions we want to make", and then discuss from there.
>
> Regards,
> Alejandro
>
>
> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
> escribió:
>
>> I think we may want to have the Committee initiate and drive the process.
>> I think a GHC20XX proposal will turn into a bunch of micro proposals and
>> discussions about individual (groups of) extensions, and it will be hard to
>> track all of the threads of discussion in a single GitHub thread. We’ve
>> dealt with long and contentious discussions before, but they were much more
>> focused than GHC20XX will be, by design.
>>
>> I suggested earlier that an alternative strategy could be to open a new
>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>> process, with each proposed group of extensions getting its own PR and
>> discussion. There are a few open questions here though. When/how do we
>> decide that it’s time for a new standard? How do we decide when the full
>> proposal is ready for review? Do we need to review and sign off on each
>> group of extensions separately or only the final product?
>>
>> This process would be a lot more work for us, so I’m happy to try the
>> usual process first, and I’ll be happy to be proved wrong. But we should be
>> prepared to step in and add some more structure if needed.
>>
>> Regardless, the first step should be to update our docs to express
>> interest in GHC20XX proposals, establish criteria for including language
>> extensions, and outline a process for submitting them.
>>
>> Eric
>>
>> Sent from my iPhone
>>
>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> 
>>
>> Personally I don’t think we should make the Steering Committee
>> responsible for initiating or driving this.  We should
>>
>>    - establish the criteria (including some idea of how frequently we’d
>>    be open to creating a new GHCxx version),
>>    - express open-ness to a proposal, and then
>>    - review proposals when/if they materialise.
>>
>>
>>
>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>> that’s different from making the committee *responsible*.
>>
>>
>>
>> What do others think?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>> *Sent:* 08 September 2020 09:13
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>> ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>
>>
>>
>> Dear all,
>>
>> I would really like to move this forward, and I would be happy to put
>> some work on it.
>>
>>
>>
>> What do you think of the following plan?
>>
>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>> think the criteria in the wiki are quite nice. Explain that one of the
>> goals is to encompass as many stable extensions as possible.
>>
>> - Reformat the list to make 3 tables: one for extensions which satisfy
>> all 5 criteria, one for extensions we want to include even if they don't,
>> and one for those which should be rejected in the light of those criteria.
>>
>>
>>
>> If the process works well, we could think about instaurating a
>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>
>> Just back from holiday. Some thoughts
>>
>> * I don’t think this mailing list is the best place for the
>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>   a committee member, possibly not) should write a proposal,
>>   and we should put it through the process.
>>
>> * We should advertise the criteria, as Richard has done on the
>>   wiki page.
>>
>> * Any such proposal should be informed by data. Notably, extension usage
>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>
>> * A proposer might also want to run a public poll, as an additional
>>   source of data
>>
>> * When it comes to the committee, we can (I guess) vote on individual
>>   extensions, rather than just accept/reject the whole thing.
>>
>> I am intrigued by the idea of using Kialo to coordinate discussion.
>> Maybe it'd work better than GitHub?  Are there other alternatives?
>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-steering-committee <ghc-steering-committee-
>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>> |  Sent: 02 September 2020 14:57
>> |  To: Eric Seidel <eric at seidel.io>
>> |  Cc: ghc-steering-committee at haskell.org
>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>> |
>> |  It seems clear that my wiki idea isn't winning the day -- I never
>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>> |  approach is that it seems hard to get good community involvement.
>> |
>> |  Richard
>> |
>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>> |  >
>> |  > Opening a regular discussion about whether and how we want to work on
>> |  GHC 2020 sounds fine, that will also give the community a place to
>> |  weigh in. I do think the eventual contents should be informed by the
>> |  community though, it shouldn’t just be us working alone.
>> |  >
>> |  > Sent from my iPhone
>> |  >
>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>> |  breitner.de
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
>> wrote:
>> |  >>
>> |  >> Hi,
>> |  >>
>> |  >> sounds plausible. It would also allow us to use tags to easily
>> |  indicate
>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
>> |  >> then filter by issue to get the current list…
>> |  >>
>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>> |  on
>> |  >>
>> |  >> * do we even want that?
>> |  >> * what are the abstract criteria (or guidelines)?
>> |  >> * what is the process?
>> |  >>
>> |  >> I believe that discussion could be done like any other proposal.
>> |  >>
>> |  >>
>> |  >> As for the process; when I brought up the idea, I was worried about
>> |  us
>> |  >> spending huge resources discussion individual extensions to death,
>> |  and
>> |  >> proposed, in the interest of efficiency and getting things done:
>> |  >>
>> |  >>> The process could be: Every member can nominate any number of
>> |  >>> extensions, to include, maybe a small rationale and then we do one
>> |  >>> round of independent approval voting, requiring a supermajority to
>> |  >>> really only pick uncontested extensions.
>> |  >>
>> |  >> So instead of long debates, we start with GHC2020 being just those
>> |  >> extensions that a supermajority on the committee considers to be ok.
>> |  >>
>> |  >> This is much more lightweight process that we could get done in a
>> |  week
>> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
>> |  >> out one or two extension that initially people are reserved about,
>> |  but
>> |  >> could be swayed after lengthy discussions. But is that worth the
>> |  >> lengthy discussion?
>> |  >>
>> |  >> cheers,
>> |  >> Joachim
>> |  >>
>> |  >> --
>> |  >> Joachim Breitner
>> |  >> mail at joachim-breitner.de
>> |  >>
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>> |  achim-
>> |  breitner.de
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
>> %7Cfa6e3a6bcdf
>> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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/20200910/6878f633/attachment-0001.html>

From mail at joachim-breitner.de  Thu Sep 10 09:33:02 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 10 Sep 2020 11:33:02 +0200
Subject: [ghc-steering-committee]  Please review #356: Linear Types arrow,
 Shepherd: Richard
Message-ID: <923d828be16dcc9885bb372e0c5097e48edee990.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

A syntax change to the linear types arrow
has been proposed by Mathieu Boespflug
https://github.com/ghc-proposals/ghc-proposals/pull/356

This is a change to the accepted linear types proposal (so no separate
link to a rendered proposal).

As usual with amendment PRs, I propose the original shepherd, in this
case Richard, as the shepherd.

Note that Mathiew has a question for us to answer as part of viewing,
see
https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690104224
so maybe also propose an answer to that?

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/



From simonpj at microsoft.com  Thu Sep 10 16:01:24 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Sep 2020 16:01:24 +0000
Subject: [ghc-steering-committee] Goals for GHC
Message-ID: <PR3PR83MB0427985482D5DD6514CF46A6AD270@PR3PR83MB0427.EURPRD83.prod.outlook.com>

Dear GHC Steering Committee
Dmitrii makes a good point about GHC in this blog post.  To discuss.
Simon


  *   Be a goalkeeper<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.us10.list-manage.com%2Ftrack%2Fclick%3Fu%3D49a6a2e17b12be2c5c4dcb232%26id%3D4f39ccf06b%26e%3Df74e57acee&data=02%7C01%7Csimonpj%40microsoft.com%7Cd9841d6e24be47aea9c308d8559259dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353434346685776&sdata=d4w9i%2Fqh0a%2F1qIDMgEuyDELOcT02qgN7Gh2S84rQedA%3D&reserved=0> by Dmitrii Kovanikov

You may find this blog post useful, if you are interested in maintaining any project for a long time and keep your sanity during this process.

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

From mail at joachim-breitner.de  Fri Sep 11 07:58:58 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 11 Sep 2020 09:58:58 +0200
Subject: [ghc-steering-committee] Please review #351: NoIcomplete,
	Shepherd: Iavor
Message-ID: <5774f6d8a740b1c57a066e85357bc9d188f34aff.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

The NoIncomplete pragma
has been proposed by John Ericson
https://github.com/ghc-proposals/ghc-proposals/pull/351
https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-sugared-incompleteness.rst

I’ll propose Iavor 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/



From trupill at gmail.com  Fri Sep 11 08:47:37 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 11 Sep 2020 10:47:37 +0200
Subject: [ghc-steering-committee] Goals for GHC
In-Reply-To: <PR3PR83MB0427985482D5DD6514CF46A6AD270@PR3PR83MB0427.EURPRD83.prod.outlook.com>
References: <PR3PR83MB0427985482D5DD6514CF46A6AD270@PR3PR83MB0427.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOv+gWoe8VAufXqFc4kR-WjxdtjLn8CTaLOn+enXFcf0pA@mail.gmail.com>

Dear all,
I've read the post, and the discussion it spawned on Reddit. I agree with a
lot with the following comment there
https://www.reddit.com/r/haskell/comments/iopcx3/blog_post_be_a_goalkeeper_what_are_the_haskell/g4fvj7d?utm_source=share&utm_medium=web2x&context=3

> I actually feel like something Haskell has always done very well is
balance the concerns of people with different goals and motivations. [...]
through its lifetime of serving as an academic research project AND an
educational tool used in freshman programming classes AND and a stable
language for production work

I have the feeling that people think that GHC is less rounded that it is
due to the myriad of extensions one needs to enable to bring some
functionality in (MultiParamTypeClasses + FlexibleInstances +
FlexibleContexts come to mind for any class-based programming). This is one
of the reasons I wanted to push the new GHC2020 "standard".

Alejandro

El jue., 10 sept. 2020 a las 18:01, Simon Peyton Jones via
ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:

> Dear GHC Steering Committee
>
> Dmitrii makes a good point about GHC in this blog post.  To discuss.
>
> Simon
>
>
>
>    - Be a goalkeeper
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.us10.list-manage.com%2Ftrack%2Fclick%3Fu%3D49a6a2e17b12be2c5c4dcb232%26id%3D4f39ccf06b%26e%3Df74e57acee&data=02%7C01%7Csimonpj%40microsoft.com%7Cd9841d6e24be47aea9c308d8559259dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353434346685776&sdata=d4w9i%2Fqh0a%2F1qIDMgEuyDELOcT02qgN7Gh2S84rQedA%3D&reserved=0>
>    by Dmitrii Kovanikov
>
> You may find this blog post useful, if you are interested in maintaining
> any project for a long time and keep your sanity during this process.
>
>
> _______________________________________________
> 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/20200911/5484b5f0/attachment.html>

From rae at richarde.dev  Fri Sep 11 15:05:25 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 11 Sep 2020 15:05:25 +0000
Subject: [ghc-steering-committee] Goals for GHC
In-Reply-To: <CAHnFXOv+gWoe8VAufXqFc4kR-WjxdtjLn8CTaLOn+enXFcf0pA@mail.gmail.com>
References: <PR3PR83MB0427985482D5DD6514CF46A6AD270@PR3PR83MB0427.EURPRD83.prod.outlook.com>
 <CAHnFXOv+gWoe8VAufXqFc4kR-WjxdtjLn8CTaLOn+enXFcf0pA@mail.gmail.com>
Message-ID: <010f01747db320e5-c25fcb73-6825-4a37-be67-ec935e8db0d6-000000@us-east-2.amazonses.com>



> On Sep 11, 2020, at 4:47 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> I have the feeling that people think that GHC is less rounded that it is due to the myriad of extensions one needs to enable to bring some functionality in (MultiParamTypeClasses + FlexibleInstances + FlexibleContexts come to mind for any class-based programming). This is one of the reasons I wanted to push the new GHC2020 "standard".

I agree. A frequent comment at events is that Haskell is just too complicated. But I think what the speakers often mean is that there are too many extensions. I've asked what people mean, and I never have felt I've gotten a more satisfactory answre than that. Happily, it's a relatively easy problem to fix!

That said, I do think writing out some goals would be a useful exercise.

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

From mail at joachim-breitner.de  Sat Sep 12 21:59:00 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 12 Sep 2020 23:59:00 +0200
Subject: [ghc-steering-committee] Please review #313: Delimited continuation
 primops, Shepherd: Simon Marlow
Message-ID: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de>

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/



From rae at richarde.dev  Sun Sep 13 22:12:07 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Sun, 13 Sep 2020 22:12:07 +0000
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear arrows
Message-ID: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>

Hi committee,

Mathieu Boespflug has proposed a new syntax for linear arrows: https://github.com/ghc-proposals/ghc-proposals/pull/356

Currently (from the original linear types proposal), we have #-> to denote a linear function, and # m -> to denote an arbitrary function whose argument has multiplicity m. This proposal suggests three changes:

1. Drop #-> entirely.
2. Use ^ instead of # in the second form, but require that it be a *prefix* usage of ^ (that is, the character after the ^ must not be  whitespace).
3. Introduce a new lexeme ^1 that is used to denote linear functions.
Alternative: use % in place of ^; % is observed to be more visually apparent in some fonts than ^.

In time, the hope is that rule (3) will no longer be needed, if we gain overloaded numbers at the type level (when 1 :: Multiplicity will type-check without a special rule).

Motivations for this change come from the experience within Tweag of using linear types. The change away from # also is to avoid a conflict with overloaded labels, once those are allowed in types.

The hope is that we can make a decision about this in time for release with GHC 9.0. This proposal is already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020

In conflict with our usual protocol, I will not make a recommendation on this proposal, as I am conflicted with the proposer. However, I do hope that we can come to a conclusion on this quickly, to avoid making a backward-incompatible change after a release.

We have four options:
A. Keep the syntax as it is.
B. Choose to go with ^
C. Choose to go with %
D. Choose to go with some other symbol. I don't think there is any particular preference for any one symbol over another.

Richard

From trupill at gmail.com  Mon Sep 14 09:16:16 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 14 Sep 2020 11:16:16 +0200
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
	arrows
In-Reply-To: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtMWZUb2Qr8jqjnMnZSM0+0OStfrnLkU8q=cvk2UcxrxA@mail.gmail.com>

Hi,
I am OK with B or C, with a slight preference with B. I am OK too with
moving this proposal fast so it can be reflected on GHC 9.0.

Regards,
Alejandro

El lun., 14 sept. 2020 a las 0:12, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> Hi committee,
>
> Mathieu Boespflug has proposed a new syntax for linear arrows:
> https://github.com/ghc-proposals/ghc-proposals/pull/356
>
> Currently (from the original linear types proposal), we have #-> to denote
> a linear function, and # m -> to denote an arbitrary function whose
> argument has multiplicity m. This proposal suggests three changes:
>
> 1. Drop #-> entirely.
> 2. Use ^ instead of # in the second form, but require that it be a
> *prefix* usage of ^ (that is, the character after the ^ must not be
> whitespace).
> 3. Introduce a new lexeme ^1 that is used to denote linear functions.
> Alternative: use % in place of ^; % is observed to be more visually
> apparent in some fonts than ^.
>
> In time, the hope is that rule (3) will no longer be needed, if we gain
> overloaded numbers at the type level (when 1 :: Multiplicity will
> type-check without a special rule).
>
> Motivations for this change come from the experience within Tweag of using
> linear types. The change away from # also is to avoid a conflict with
> overloaded labels, once those are allowed in types.
>
> The hope is that we can make a decision about this in time for release
> with GHC 9.0. This proposal is already implemented:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020
>
> In conflict with our usual protocol, I will not make a recommendation on
> this proposal, as I am conflicted with the proposer. However, I do hope
> that we can come to a conclusion on this quickly, to avoid making a
> backward-incompatible change after a release.
>
> We have four options:
> A. Keep the syntax as it is.
> B. Choose to go with ^
> C. Choose to go with %
> D. Choose to go with some other symbol. I don't think there is any
> particular preference for any one symbol over another.
>
> 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/20200914/ef06a81a/attachment.html>

From simonpj at microsoft.com  Mon Sep 14 14:56:27 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Sep 2020 14:56:27 +0000
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
 arrows
In-Reply-To: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB0429EEFB59D2EB5B92F2833CAD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>

I am supportive.

I mildly prefer '%' to '^', purely on grounds of visibility.  But I do not feel strongly.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Richard Eisenberg
|  Sent: 13 September 2020 23:12
|  To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-
|  committee at haskell.org>
|  Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
|  arrows
|  
|  Hi committee,
|  
|  Mathieu Boespflug has proposed a new syntax for linear arrows:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F356&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C054
|  4526238754e222e3208d85832156e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
|  0%7C637356319418315258&amp;sdata=3266N3ZptTbLQ2EpNgDJh1C1LarPmbUkXAgKcl
|  6%2BeE0%3D&amp;reserved=0
|  
|  Currently (from the original linear types proposal), we have #-> to
|  denote a linear function, and # m -> to denote an arbitrary function
|  whose argument has multiplicity m. This proposal suggests three
|  changes:
|  
|  1. Drop #-> entirely.
|  2. Use ^ instead of # in the second form, but require that it be a
|  *prefix* usage of ^ (that is, the character after the ^ must not be
|  whitespace).
|  3. Introduce a new lexeme ^1 that is used to denote linear functions.
|  Alternative: use % in place of ^; % is observed to be more visually
|  apparent in some fonts than ^.
|  
|  In time, the hope is that rule (3) will no longer be needed, if we gain
|  overloaded numbers at the type level (when 1 :: Multiplicity will type-
|  check without a special rule).
|  
|  Motivations for this change come from the experience within Tweag of
|  using linear types. The change away from # also is to avoid a conflict
|  with overloaded labels, once those are allowed in types.
|  
|  The hope is that we can make a decision about this in time for release
|  with GHC 9.0. This proposal is already implemented:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Fghc%2Fghc%2F-
|  %2Fmerge_requests%2F4020&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
|  544526238754e222e3208d85832156e%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637356319418315258&amp;sdata=kp4HBcTvHu6FPAREC4vD3mVfDMbnMztYgW%2
|  FPvHTUr0A%3D&amp;reserved=0
|  
|  In conflict with our usual protocol, I will not make a recommendation
|  on this proposal, as I am conflicted with the proposer. However, I do
|  hope that we can come to a conclusion on this quickly, to avoid making
|  a backward-incompatible change after a release.
|  
|  We have four options:
|  A. Keep the syntax as it is.
|  B. Choose to go with ^
|  C. Choose to go with %
|  D. Choose to go with some other symbol. I don't think there is any
|  particular preference for any one symbol over another.
|  
|  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=02%7C01%7Csimonpj%40microsoft.com%7C0544526238754e22
|  2e3208d85832156e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356319
|  418315258&amp;sdata=tkqtcIuFROPvwmEG3gd9zPtcrbhL5cyVN4vNdJqEv1M%3D&amp;
|  reserved=0

From mail at joachim-breitner.de  Mon Sep 14 16:23:16 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Sep 2020 18:23:16 +0200
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
 arrows
In-Reply-To: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
Message-ID: <dfb1fb4549609bcf6463fe85b8e5d4f9b924cf2b.camel@joachim-breitner.de>

How annoying, how can I now say “I’m trusting the shepherd’s
judgement” … ;-)

I guess in that case I’ll say I’m trusting Simon PJ, and will go with
his vote, as I have no strong opinion of my own.

Cheers,
Joachim


Am Sonntag, den 13.09.2020, 22:12 +0000 schrieb Richard Eisenberg:
> Hi committee,
> 
> Mathieu Boespflug has proposed a new syntax for linear arrows: https://github.com/ghc-proposals/ghc-proposals/pull/356
> 
> Currently (from the original linear types proposal), we have #-> to denote a linear function, and # m -> to denote an arbitrary function whose argument has multiplicity m. This proposal suggests three changes:
> 
> 1. Drop #-> entirely.
> 2. Use ^ instead of # in the second form, but require that it be a *prefix* usage of ^ (that is, the character after the ^ must not be  whitespace).
> 3. Introduce a new lexeme ^1 that is used to denote linear functions.
> Alternative: use % in place of ^; % is observed to be more visually apparent in some fonts than ^.
> 
> In time, the hope is that rule (3) will no longer be needed, if we gain overloaded numbers at the type level (when 1 :: Multiplicity will type-check without a special rule).
> 
> Motivations for this change come from the experience within Tweag of using linear types. The change away from # also is to avoid a conflict with overloaded labels, once those are allowed in types.
> 
> The hope is that we can make a decision about this in time for release with GHC 9.0. This proposal is already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020
> 
> In conflict with our usual protocol, I will not make a recommendation on this proposal, as I am conflicted with the proposer. However, I do hope that we can come to a conclusion on this quickly, to avoid making a backward-incompatible change after a release.
> 
> We have four options:
> A. Keep the syntax as it is.
> B. Choose to go with ^
> C. Choose to go with %
> D. Choose to go with some other symbol. I don't think there is any particular preference for any one symbol over another.
> 
> Richard
> _______________________________________________
> 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 arnaud.spiwack at tweag.io  Tue Sep 15 06:57:09 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 15 Sep 2020 08:57:09 +0200
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
	arrows
In-Reply-To: <dfb1fb4549609bcf6463fe85b8e5d4f9b924cf2b.camel@joachim-breitner.de>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
 <dfb1fb4549609bcf6463fe85b8e5d4f9b924cf2b.camel@joachim-breitner.de>
Message-ID: <CAH6fHQ=aBHaUK2S8cvxuJevd_LytW7WaT0bLW2XG=iG5U7f6ZQ@mail.gmail.com>

After looking at the renderings in
https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690221468
, I do prefer `^` over `%`. Not very strongly either.

On Mon, Sep 14, 2020 at 6:23 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> How annoying, how can I now say “I’m trusting the shepherd’s
> judgement” … ;-)
>
> I guess in that case I’ll say I’m trusting Simon PJ, and will go with
> his vote, as I have no strong opinion of my own.
>
> Cheers,
> Joachim
>
>
> Am Sonntag, den 13.09.2020, 22:12 +0000 schrieb Richard Eisenberg:
> > Hi committee,
> >
> > Mathieu Boespflug has proposed a new syntax for linear arrows:
> https://github.com/ghc-proposals/ghc-proposals/pull/356
> >
> > Currently (from the original linear types proposal), we have #-> to
> denote a linear function, and # m -> to denote an arbitrary function whose
> argument has multiplicity m. This proposal suggests three changes:
> >
> > 1. Drop #-> entirely.
> > 2. Use ^ instead of # in the second form, but require that it be a
> *prefix* usage of ^ (that is, the character after the ^ must not be
> whitespace).
> > 3. Introduce a new lexeme ^1 that is used to denote linear functions.
> > Alternative: use % in place of ^; % is observed to be more visually
> apparent in some fonts than ^.
> >
> > In time, the hope is that rule (3) will no longer be needed, if we gain
> overloaded numbers at the type level (when 1 :: Multiplicity will
> type-check without a special rule).
> >
> > Motivations for this change come from the experience within Tweag of
> using linear types. The change away from # also is to avoid a conflict with
> overloaded labels, once those are allowed in types.
> >
> > The hope is that we can make a decision about this in time for release
> with GHC 9.0. This proposal is already implemented:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020
> >
> > In conflict with our usual protocol, I will not make a recommendation on
> this proposal, as I am conflicted with the proposer. However, I do hope
> that we can come to a conclusion on this quickly, to avoid making a
> backward-incompatible change after a release.
> >
> > We have four options:
> > A. Keep the syntax as it is.
> > B. Choose to go with ^
> > C. Choose to go with %
> > D. Choose to go with some other symbol. I don't think there is any
> particular preference for any one symbol over another.
> >
> > Richard
> > _______________________________________________
> > 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/
>
>
> _______________________________________________
> 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/20200915/1684dd85/attachment.html>

From arnaud.spiwack at tweag.io  Wed Sep 16 09:47:38 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 16 Sep 2020 11:47:38 +0200
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <CAGK9nurkZr0NJTexjhxY-sH9QDa34ZPXVhvXQfawVb97+w=rNg@mail.gmail.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CAHnFXOuj8Yc+C=GQZEpTtn2qVfVj7qnavRdn50S1yUo-rmQy9g@mail.gmail.com>
 <010f0174599d139f-97b92a93-9d9f-4f21-89ed-dcdae14c6ba9-000000@us-east-2.amazonses.com>
 <CAHnFXOtOwnW_OycxCyURssqdgnDDtMDHMOw2oOzzayQk6hD+nw@mail.gmail.com>
 <CAGK9nurkZr0NJTexjhxY-sH9QDa34ZPXVhvXQfawVb97+w=rNg@mail.gmail.com>
Message-ID: <CAH6fHQkAmSodd_YSbQmQs4p0Nc1n1pOwX=2t9mYrg5OcXO8j-w@mail.gmail.com>

I am broadly supportive of this issue. I do find the `of` keyword rather
off-putting. But I could live with it.

Many variations are being mooted on the github thread, I don't really have
an opinion among all of these yet.

On Fri, Sep 4, 2020 at 6:04 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I am not sure what problem we are solving, and I doubt this would lead to
> more readable Haskell, or more streamlined language definition.  So what's
> the gain?
>
>
> On Fri, Sep 4, 2020 at 7:57 AM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> I think that would work pretty well. In fact, the implementation of such
>> a rule would allow us to also point beginners when they need parentheses in
>> regular pattern matching!
>>
>> El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg (<rae at richarde.dev>)
>> escribió:
>>
>>> Thinking about disambiguating \case Just x -> x: There is no way that
>>> \of Just x -> ... can be correct, because Just requires an argument. Very
>>> happily, the renamer's behavior is unaffected: any variables introduced are
>>> still binding sites. So, I think we could probably detect a case like this
>>> in the type-checker and either reinterpret it correct or provide a very
>>> helpful error message.
>>>
>>> So here's a concrete idea:
>>>
>>> - Change the existing proposal to use \case instead of \of.
>>> - Add a little magic to the type-checker, as specified below, to allow
>>> current usages of \case to be accepted.
>>> - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on
>>> by default).
>>> - Remove the magic (and its warning) in a few releases.
>>>
>>> The magic:
>>> - The new construct allows many patterns before the -> where the old
>>> \case allowed only one.
>>> - The type-checker detects when the first of these patterns is a
>>> solitary constructor, and when this constructor is not nullary.
>>> - It then reconstructs the AST to move the remaining patterns as
>>> arguments of that first one. Because our AST tracks parens manually, the
>>> new AST will even print identically to the old one.
>>>
>>> This magic is, well, magical, but it's well specified, backward
>>> compatible, and unambiguous.
>>>
>>> What do we think?
>>>
>>> Richard
>>>
>>> On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>> Hi all,
>>> I agree with the sentiment. I think adding \of would be a nice way to
>>> clean up the language (in the same way that now StandaloneKindSignatures
>>> allow us to remove the weirder CUSKs), but unless we have some deprecation
>>> policy for extensions, this may confuse people more than help.
>>>
>>> It's particularly bad that we cannot make this simply an extension of
>>> \case, due to the example pointed out in the thread: \case Just x -> x.
>>> Could we maybe think of some way to disambiguate those cases? I'm going to
>>> ask this in the thread too.
>>>
>>> Regards,
>>> Alejandro
>>>
>>> El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev>)
>>> escribió:
>>>
>>>> Hi all,
>>>>
>>>> Proposal #302 was submitted to the committee and assigned to Cale. He
>>>> has made a recommendation on the GitHub trail, but I don't believe the
>>>> committee has discussed this among ourselves.
>>>>
>>>> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
>>>> Proposal:
>>>> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
>>>> Cale's recommendation:
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>>>>
>>>> The idea, in brief, is to introduce a new syntax (guarded behind
>>>> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>>>>
>>>> mplus :: Maybe Int -> Maybe Int -> Maybe Int
>>>> mplus = \of
>>>>   Nothing _ -> Nothing
>>>>   _ Nothing -> Nothing
>>>>   (Just x) (Just y) -> Just (x + y)
>>>>
>>>> The new keyword allows us to use a syntax similar to function
>>>> definitions, but without repeating the name of the function. It is also
>>>> like \case, but it allows multiple arguments. Guards are allowed, as usual.
>>>>
>>>> I really like this new syntax -- mostly because I find it very strange
>>>> that we have to repeat the function name on every line. And then change the
>>>> spacing when we change the function name. And I like the mnemonic "lambda
>>>> of". And it allows me to write a where clause that is accessible in
>>>> multiple different patterns, or an indented where clause that is usable in
>>>> just one. If it didn't confuse readers, I would use this syntax all the
>>>> time.
>>>>
>>>> Even so, I agree with Cale's recommendation to reject. We just have too
>>>> much syntax! If someone were to come along and draft a concrete proposal of
>>>> how we could, for example, use this syntax to replace both \case and if|,
>>>> with a migration strategy, etc., then I might be in favor. Until then, I
>>>> think we've spent our budget for cute, obscure bits of syntax.
>>>>
>>>> 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/20200916/1f7bec32/attachment.html>

From marlowsd at gmail.com  Thu Sep 17 14:42:17 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Sep 2020 15:42:17 +0100
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
Message-ID: <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>

I think there should be some requirement that an extension be widely-used
(for some suitable definition of that), before we ratify it in GHC2020.
Some of the extensions that made it past the first round of filtering are
not widely-used, and would be therefore probably be controversial additions
to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
to name a few that I noticed straight off. I think it's a good idea to be
conservative here.

Cheers
Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> There seems to be some question about who should drive this debate. But
> there is something we all seem to agree on: it is our role, as the steering
> committee, to announce the criteria by which we intend to judge the
> reasonableness of each potential candidate extension.
>
> So, let me suggest that we start discussing that, and move back to how
> this discussion ought to be driven when we are a bit clearer on the
> criteria.
>
> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
> that they are worthy of discussion. So let me ask the question: do we agree
> with all these criteria? do we want to add more?
>
> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>
> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> I would rather make the process Committee-driven, because otherwise it
>> may derail into too many micro-discussions. I think it's better to start a
>> conversation saying "this is our proposal, here are our criteria, here are
>> the exceptions we want to make", and then discuss from there.
>>
>> Regards,
>> Alejandro
>>
>>
>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>> escribió:
>>
>>> I think we may want to have the Committee initiate and drive the
>>> process. I think a GHC20XX proposal will turn into a bunch of micro
>>> proposals and discussions about individual (groups of) extensions, and it
>>> will be hard to track all of the threads of discussion in a single GitHub
>>> thread. We’ve dealt with long and contentious discussions before, but they
>>> were much more focused than GHC20XX will be, by design.
>>>
>>> I suggested earlier that an alternative strategy could be to open a new
>>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>>> process, with each proposed group of extensions getting its own PR and
>>> discussion. There are a few open questions here though. When/how do we
>>> decide that it’s time for a new standard? How do we decide when the full
>>> proposal is ready for review? Do we need to review and sign off on each
>>> group of extensions separately or only the final product?
>>>
>>> This process would be a lot more work for us, so I’m happy to try the
>>> usual process first, and I’ll be happy to be proved wrong. But we should be
>>> prepared to step in and add some more structure if needed.
>>>
>>> Regardless, the first step should be to update our docs to express
>>> interest in GHC20XX proposals, establish criteria for including language
>>> extensions, and outline a process for submitting them.
>>>
>>> Eric
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>
>>> 
>>>
>>> Personally I don’t think we should make the Steering Committee
>>> responsible for initiating or driving this.  We should
>>>
>>>    - establish the criteria (including some idea of how frequently we’d
>>>    be open to creating a new GHCxx version),
>>>    - express open-ness to a proposal, and then
>>>    - review proposals when/if they materialise.
>>>
>>>
>>>
>>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>>> that’s different from making the committee *responsible*.
>>>
>>>
>>>
>>> What do others think?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 08 September 2020 09:13
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>>> ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> Dear all,
>>>
>>> I would really like to move this forward, and I would be happy to put
>>> some work on it.
>>>
>>>
>>>
>>> What do you think of the following plan?
>>>
>>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>>> think the criteria in the wiki are quite nice. Explain that one of the
>>> goals is to encompass as many stable extensions as possible.
>>>
>>> - Reformat the list to make 3 tables: one for extensions which satisfy
>>> all 5 criteria, one for extensions we want to include even if they don't,
>>> and one for those which should be rejected in the light of those criteria.
>>>
>>>
>>>
>>> If the process works well, we could think about instaurating a
>>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>>
>>> Just back from holiday. Some thoughts
>>>
>>> * I don’t think this mailing list is the best place for the
>>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>>   a committee member, possibly not) should write a proposal,
>>>   and we should put it through the process.
>>>
>>> * We should advertise the criteria, as Richard has done on the
>>>   wiki page.
>>>
>>> * Any such proposal should be informed by data. Notably, extension usage
>>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>>
>>> * A proposer might also want to run a public poll, as an additional
>>>   source of data
>>>
>>> * When it comes to the committee, we can (I guess) vote on individual
>>>   extensions, rather than just accept/reject the whole thing.
>>>
>>> I am intrigued by the idea of using Kialo to coordinate discussion.
>>> Maybe it'd work better than GitHub?  Are there other alternatives?
>>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>>
>>> Simon
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-steering-committee <ghc-steering-committee-
>>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>>> |  Sent: 02 September 2020 14:57
>>> |  To: Eric Seidel <eric at seidel.io>
>>> |  Cc: ghc-steering-committee at haskell.org
>>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>>> |
>>> |  It seems clear that my wiki idea isn't winning the day -- I never
>>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>>> |  approach is that it seems hard to get good community involvement.
>>> |
>>> |  Richard
>>> |
>>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>>> |  >
>>> |  > Opening a regular discussion about whether and how we want to work
>>> on
>>> |  GHC 2020 sounds fine, that will also give the community a place to
>>> |  weigh in. I do think the eventual contents should be informed by the
>>> |  community though, it shouldn’t just be us working alone.
>>> |  >
>>> |  > Sent from my iPhone
>>> |  >
>>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
>>> wrote:
>>> |  >>
>>> |  >> Hi,
>>> |  >>
>>> |  >> sounds plausible. It would also allow us to use tags to easily
>>> |  indicate
>>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…),
>>> and
>>> |  >> then filter by issue to get the current list…
>>> |  >>
>>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>>> |  on
>>> |  >>
>>> |  >> * do we even want that?
>>> |  >> * what are the abstract criteria (or guidelines)?
>>> |  >> * what is the process?
>>> |  >>
>>> |  >> I believe that discussion could be done like any other proposal.
>>> |  >>
>>> |  >>
>>> |  >> As for the process; when I brought up the idea, I was worried about
>>> |  us
>>> |  >> spending huge resources discussion individual extensions to death,
>>> |  and
>>> |  >> proposed, in the interest of efficiency and getting things done:
>>> |  >>
>>> |  >>> The process could be: Every member can nominate any number of
>>> |  >>> extensions, to include, maybe a small rationale and then we do one
>>> |  >>> round of independent approval voting, requiring a supermajority to
>>> |  >>> really only pick uncontested extensions.
>>> |  >>
>>> |  >> So instead of long debates, we start with GHC2020 being just those
>>> |  >> extensions that a supermajority on the committee considers to be
>>> ok.
>>> |  >>
>>> |  >> This is much more lightweight process that we could get done in a
>>> |  week
>>> |  >> or two (maybe using a doodle-like voting page). Maybe we would
>>> leave
>>> |  >> out one or two extension that initially people are reserved about,
>>> |  but
>>> |  >> could be swayed after lengthy discussions. But is that worth the
>>> |  >> lengthy discussion?
>>> |  >>
>>> |  >> cheers,
>>> |  >> Joachim
>>> |  >>
>>> |  >> --
>>> |  >> Joachim Breitner
>>> |  >> mail at joachim-breitner.de
>>> |  >>
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>>> |  achim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
>>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
>>> %7Cfa6e3a6bcdf
>>> |
>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>> |
>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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
>>
> _______________________________________________
> 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/20200917/dde60f70/attachment-0001.html>

From marlowsd at gmail.com  Thu Sep 17 14:53:20 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Sep 2020 15:53:20 +0100
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>

Cale's rationale chimes with me. A lot - I feel like I might have even made
the same point in previous threads on this. I think of the tradeoff like
this:

* The lack of \of doesn't really hurt very much. In fact, arguably by
forcing the author to type some more characters and give something a name,
we get code that's clearer for the reader. (yes this is very subjective,
but syntax is).
* The addition of \of *would* hurt new users of the language. Only a bit,
but every bit makes things worse, and things are already quite bad.

Cheers
Simon

On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> Proposal #302 was submitted to the committee and assigned to Cale. He has
> made a recommendation on the GitHub trail, but I don't believe the
> committee has discussed this among ourselves.
>
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
> Proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
> Cale's recommendation:
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>
> The idea, in brief, is to introduce a new syntax (guarded behind
> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>
> mplus :: Maybe Int -> Maybe Int -> Maybe Int
> mplus = \of
>   Nothing _ -> Nothing
>   _ Nothing -> Nothing
>   (Just x) (Just y) -> Just (x + y)
>
> The new keyword allows us to use a syntax similar to function definitions,
> but without repeating the name of the function. It is also like \case, but
> it allows multiple arguments. Guards are allowed, as usual.
>
> I really like this new syntax -- mostly because I find it very strange
> that we have to repeat the function name on every line. And then change the
> spacing when we change the function name. And I like the mnemonic "lambda
> of". And it allows me to write a where clause that is accessible in
> multiple different patterns, or an indented where clause that is usable in
> just one. If it didn't confuse readers, I would use this syntax all the
> time.
>
> Even so, I agree with Cale's recommendation to reject. We just have too
> much syntax! If someone were to come along and draft a concrete proposal of
> how we could, for example, use this syntax to replace both \case and if|,
> with a migration strategy, etc., then I might be in favor. Until then, I
> think we've spent our budget for cute, obscure bits of syntax.
>
> 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/20200917/504de857/attachment.html>

From simonpj at microsoft.com  Thu Sep 17 15:22:53 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Sep 2020 15:22:53 +0000
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>
Message-ID: <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

If it was re-cast as \mcase, which is just like \case but allows n-ary functions, I’d find it quite acceptable.  The two then become extremely close, so there’s a very low cognitive load.

GHC’s internals already allow this, and it seems surprisingly non-orthogonal that the source language does not.

We could kill off MultiWayIf.

But I don’t feel strongly.  If a consensus does not emerge, maybe we should just vote.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 17 September 2020 15:53
To: Richard Eisenberg <rae at richarde.dev>
Cc: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Proposal #302: `\of`

Cale's rationale chimes with me. A lot - I feel like I might have even made the same point in previous threads on this. I think of the tradeoff like this:

* The lack of \of doesn't really hurt very much. In fact, arguably by forcing the author to type some more characters and give something a name, we get code that's clearer for the reader. (yes this is very subjective, but syntax is).
* The addition of \of *would* hurt new users of the language. Only a bit, but every bit makes things worse, and things are already quite bad.

Cheers
Simon

On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:
Hi all,

Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.

PR: https://github.com/ghc-proposals/ghc-proposals/pull/302<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199745852&sdata=dTBwWAv4oSLAVZXcCimFWfeNygnz%2FKcadcWw0YNdcuk%3D&reserved=0>
Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MusKqbiaRHp2rbPuyFQTYYiSP9%2FjGkwKKmPoPwRu1qc%3D&reserved=0>
Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-666075014&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MiDN5T22uVYITKYiB3yyyqrhe%2FleEKLvJk%2FjnaiVI7Y%3D&reserved=0>

The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:

mplus :: Maybe Int -> Maybe Int -> Maybe Int
mplus = \of
  Nothing _ -> Nothing
  _ Nothing -> Nothing
  (Just x) (Just y) -> Just (x + y)

The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.

I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.

Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.

Richard
_______________________________________________
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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199765841&sdata=zraLb1BkWyd7RIDmN7GR%2B5IUJwzbetShFqcsp4RwLGQ%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200917/3aeaa069/attachment-0001.html>

From trupill at gmail.com  Thu Sep 17 15:34:37 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 17 Sep 2020 17:34:37 +0200
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>
 <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOtv=yG5nupYRhB_gCEqfq=GR1D=QPXvyevJPoG=9feu2g@mail.gmail.com>

What about introducing both "mcase ... of" and "\mcase"? That way we keep
the existing similarity between "case ... of" and "\case", but extended to
multiple arguments.

Alejandro

El jue., 17 sept. 2020 a las 17:23, Simon Peyton Jones via
ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:

> If it was re-cast as \mcase, which is just like \case but allows n-ary
> functions, I’d find it quite acceptable.  The two then become extremely
> close, so there’s a very low cognitive load.
>
>
>
> GHC’s internals already allow this, and it seems surprisingly
> non-orthogonal that the source language does not.
>
>
>
> We could kill off MultiWayIf.
>
>
>
> But I don’t feel strongly.  If a consensus does not emerge, maybe we
> should just vote.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 17 September 2020 15:53
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of`
>
>
>
> Cale's rationale chimes with me. A lot - I feel like I might have even
> made the same point in previous threads on this. I think of the tradeoff
> like this:
>
>
>
> * The lack of \of doesn't really hurt very much. In fact, arguably by
> forcing the author to type some more characters and give something a name,
> we get code that's clearer for the reader. (yes this is very subjective,
> but syntax is).
>
> * The addition of \of *would* hurt new users of the language. Only a bit,
> but every bit makes things worse, and things are already quite bad.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg <rae at richarde.dev> wrote:
>
> Hi all,
>
> Proposal #302 was submitted to the committee and assigned to Cale. He has
> made a recommendation on the GitHub trail, but I don't believe the
> committee has discussed this among ourselves.
>
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199745852&sdata=dTBwWAv4oSLAVZXcCimFWfeNygnz%2FKcadcWw0YNdcuk%3D&reserved=0>
> Proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MusKqbiaRHp2rbPuyFQTYYiSP9%2FjGkwKKmPoPwRu1qc%3D&reserved=0>
> Cale's recommendation:
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-666075014&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MiDN5T22uVYITKYiB3yyyqrhe%2FleEKLvJk%2FjnaiVI7Y%3D&reserved=0>
>
> The idea, in brief, is to introduce a new syntax (guarded behind
> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>
> mplus :: Maybe Int -> Maybe Int -> Maybe Int
> mplus = \of
>   Nothing _ -> Nothing
>   _ Nothing -> Nothing
>   (Just x) (Just y) -> Just (x + y)
>
> The new keyword allows us to use a syntax similar to function definitions,
> but without repeating the name of the function. It is also like \case, but
> it allows multiple arguments. Guards are allowed, as usual.
>
> I really like this new syntax -- mostly because I find it very strange
> that we have to repeat the function name on every line. And then change the
> spacing when we change the function name. And I like the mnemonic "lambda
> of". And it allows me to write a where clause that is accessible in
> multiple different patterns, or an indented where clause that is usable in
> just one. If it didn't confuse readers, I would use this syntax all the
> time.
>
> Even so, I agree with Cale's recommendation to reject. We just have too
> much syntax! If someone were to come along and draft a concrete proposal of
> how we could, for example, use this syntax to replace both \case and if|,
> with a migration strategy, etc., then I might be in favor. Until then, I
> think we've spent our budget for cute, obscure bits of syntax.
>
> Richard
> _______________________________________________
> 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199765841&sdata=zraLb1BkWyd7RIDmN7GR%2B5IUJwzbetShFqcsp4RwLGQ%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/20200917/3d62f921/attachment.html>

From trupill at gmail.com  Thu Sep 17 15:39:08 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 17 Sep 2020 17:39:08 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
Message-ID: <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>

I agree with using the criteria that Richard posted + the addition by
Simon. Just in case somebody hadn't looked at the wiki, the criteria would
be:

   1.

   The extension is (mostly) conservative: All programs that were accepted
   without the extension remain accepted, and with the same meaning.
   2.

   New failure modes that become possible with the extension are rare
   and/or easy to diagnose. (These failure modes include new error messages,
   wrong inferred types, and runtime errors, for example.)
   3.

   The extensions complement the design of standard Haskell. (This one
   seems the most subjective.)
   4.

   The extension has been -- and can reasonably be predicted to remain --
   stable.
   5.

   The extension is not to gate-keep an advanced or potentially-unsafe
   feature.
   6. The extension is widely-used.

For example, should we add to (6) "in current developments"? What about
things like "EmptyDataDecls", which are just straightforward
generalizations of what Haskell 2010 already allows, although in practice
the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
escribió:

> I think there should be some requirement that an extension be widely-used
> (for some suitable definition of that), before we ratify it in GHC2020.
> Some of the extensions that made it past the first round of filtering are
> not widely-used, and would be therefore probably be controversial additions
> to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
> to name a few that I noticed straight off. I think it's a good idea to be
> conservative here.
>
> Cheers
> Simon
>
> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>> There seems to be some question about who should drive this debate. But
>> there is something we all seem to agree on: it is our role, as the steering
>> committee, to announce the criteria by which we intend to judge the
>> reasonableness of each potential candidate extension.
>>
>> So, let me suggest that we start discussing that, and move back to how
>> this discussion ought to be driven when we are a bit clearer on the
>> criteria.
>>
>> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
>> that they are worthy of discussion. So let me ask the question: do we agree
>> with all these criteria? do we want to add more?
>>
>> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>>
>> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>>> I would rather make the process Committee-driven, because otherwise it
>>> may derail into too many micro-discussions. I think it's better to start a
>>> conversation saying "this is our proposal, here are our criteria, here are
>>> the exceptions we want to make", and then discuss from there.
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>>> escribió:
>>>
>>>> I think we may want to have the Committee initiate and drive the
>>>> process. I think a GHC20XX proposal will turn into a bunch of micro
>>>> proposals and discussions about individual (groups of) extensions, and it
>>>> will be hard to track all of the threads of discussion in a single GitHub
>>>> thread. We’ve dealt with long and contentious discussions before, but they
>>>> were much more focused than GHC20XX will be, by design.
>>>>
>>>> I suggested earlier that an alternative strategy could be to open a new
>>>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>>>> process, with each proposed group of extensions getting its own PR and
>>>> discussion. There are a few open questions here though. When/how do we
>>>> decide that it’s time for a new standard? How do we decide when the full
>>>> proposal is ready for review? Do we need to review and sign off on each
>>>> group of extensions separately or only the final product?
>>>>
>>>> This process would be a lot more work for us, so I’m happy to try the
>>>> usual process first, and I’ll be happy to be proved wrong. But we should be
>>>> prepared to step in and add some more structure if needed.
>>>>
>>>> Regardless, the first step should be to update our docs to express
>>>> interest in GHC20XX proposals, establish criteria for including language
>>>> extensions, and outline a process for submitting them.
>>>>
>>>> Eric
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>>>> wrote:
>>>>
>>>> 
>>>>
>>>> Personally I don’t think we should make the Steering Committee
>>>> responsible for initiating or driving this.  We should
>>>>
>>>>    - establish the criteria (including some idea of how frequently
>>>>    we’d be open to creating a new GHCxx version),
>>>>    - express open-ness to a proposal, and then
>>>>    - review proposals when/if they materialise.
>>>>
>>>>
>>>>
>>>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>>>> that’s different from making the committee *responsible*.
>>>>
>>>>
>>>>
>>>> What do others think?
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>> *Sent:* 08 September 2020 09:13
>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>>>> ghc-steering-committee at haskell.org
>>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>>
>>>>
>>>>
>>>> Dear all,
>>>>
>>>> I would really like to move this forward, and I would be happy to put
>>>> some work on it.
>>>>
>>>>
>>>>
>>>> What do you think of the following plan?
>>>>
>>>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>>>> think the criteria in the wiki are quite nice. Explain that one of the
>>>> goals is to encompass as many stable extensions as possible.
>>>>
>>>> - Reformat the list to make 3 tables: one for extensions which satisfy
>>>> all 5 criteria, one for extensions we want to include even if they don't,
>>>> and one for those which should be rejected in the light of those criteria.
>>>>
>>>>
>>>>
>>>> If the process works well, we could think about instaurating a
>>>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Alejandro
>>>>
>>>>
>>>>
>>>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>>>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>>>
>>>> Just back from holiday. Some thoughts
>>>>
>>>> * I don’t think this mailing list is the best place for the
>>>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>>>   a committee member, possibly not) should write a proposal,
>>>>   and we should put it through the process.
>>>>
>>>> * We should advertise the criteria, as Richard has done on the
>>>>   wiki page.
>>>>
>>>> * Any such proposal should be informed by data. Notably, extension usage
>>>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>>>
>>>> * A proposer might also want to run a public poll, as an additional
>>>>   source of data
>>>>
>>>> * When it comes to the committee, we can (I guess) vote on individual
>>>>   extensions, rather than just accept/reject the whole thing.
>>>>
>>>> I am intrigued by the idea of using Kialo to coordinate discussion.
>>>> Maybe it'd work better than GitHub?  Are there other alternatives?
>>>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>>>
>>>> Simon
>>>>
>>>> |  -----Original Message-----
>>>> |  From: ghc-steering-committee <ghc-steering-committee-
>>>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>>>> |  Sent: 02 September 2020 14:57
>>>> |  To: Eric Seidel <eric at seidel.io>
>>>> |  Cc: ghc-steering-committee at haskell.org
>>>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>>>> |
>>>> |  It seems clear that my wiki idea isn't winning the day -- I never
>>>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>>>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>>>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>>>> |  approach is that it seems hard to get good community involvement.
>>>> |
>>>> |  Richard
>>>> |
>>>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>>>> |  >
>>>> |  > Opening a regular discussion about whether and how we want to work
>>>> on
>>>> |  GHC 2020 sounds fine, that will also give the community a place to
>>>> |  weigh in. I do think the eventual contents should be informed by the
>>>> |  community though, it shouldn’t just be us working alone.
>>>> |  >
>>>> |  > Sent from my iPhone
>>>> |  >
>>>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>>>> |  breitner.de
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
>>>> wrote:
>>>> |  >>
>>>> |  >> Hi,
>>>> |  >>
>>>> |  >> sounds plausible. It would also allow us to use tags to easily
>>>> |  indicate
>>>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…),
>>>> and
>>>> |  >> then filter by issue to get the current list…
>>>> |  >>
>>>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>>>> |  on
>>>> |  >>
>>>> |  >> * do we even want that?
>>>> |  >> * what are the abstract criteria (or guidelines)?
>>>> |  >> * what is the process?
>>>> |  >>
>>>> |  >> I believe that discussion could be done like any other proposal.
>>>> |  >>
>>>> |  >>
>>>> |  >> As for the process; when I brought up the idea, I was worried
>>>> about
>>>> |  us
>>>> |  >> spending huge resources discussion individual extensions to death,
>>>> |  and
>>>> |  >> proposed, in the interest of efficiency and getting things done:
>>>> |  >>
>>>> |  >>> The process could be: Every member can nominate any number of
>>>> |  >>> extensions, to include, maybe a small rationale and then we do
>>>> one
>>>> |  >>> round of independent approval voting, requiring a supermajority
>>>> to
>>>> |  >>> really only pick uncontested extensions.
>>>> |  >>
>>>> |  >> So instead of long debates, we start with GHC2020 being just those
>>>> |  >> extensions that a supermajority on the committee considers to be
>>>> ok.
>>>> |  >>
>>>> |  >> This is much more lightweight process that we could get done in a
>>>> |  week
>>>> |  >> or two (maybe using a doodle-like voting page). Maybe we would
>>>> leave
>>>> |  >> out one or two extension that initially people are reserved about,
>>>> |  but
>>>> |  >> could be swayed after lengthy discussions. But is that worth the
>>>> |  >> lengthy discussion?
>>>> |  >>
>>>> |  >> cheers,
>>>> |  >> Joachim
>>>> |  >>
>>>> |  >> --
>>>> |  >> Joachim Breitner
>>>> |  >> mail at joachim-breitner.de
>>>> |  >>
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>>>> |  achim-
>>>> |  breitner.de
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
>>>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf
>>>> |
>>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>>> |
>>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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
>>>
>> _______________________________________________
>> 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/20200917/d15eeca4/attachment-0001.html>

From marlowsd at gmail.com  Thu Sep 17 15:52:47 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Sep 2020 16:52:47 +0100
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>
 <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPKnuNj5afHbJeKMwKGcu6a1dOux6L_0yvDg1Tber1a7JA@mail.gmail.com>

I use MultiWayIf occasionally, but I would probably not use it at all if I
had to type "\mcase" rather than "if".  I mean, that just feels too obscure
and ugly - yes it's kind of cute that it falls out as the degenerate case
of zero arguments, but I find it strange that I could write something that
looks like a lambda and not get a lambda, and "mcase" is just
obscure-sounding.

I probably wouldn't object all that much to getting rid of MultiWayIf, it
might not be paying its way, but I'm not convinced that \mcase or \of would
pay their way either.

Cheers
Simon


On Thu, 17 Sep 2020 at 16:22, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> If it was re-cast as \mcase, which is just like \case but allows n-ary
> functions, I’d find it quite acceptable.  The two then become extremely
> close, so there’s a very low cognitive load.
>
>
>
> GHC’s internals already allow this, and it seems surprisingly
> non-orthogonal that the source language does not.
>
>
>
> We could kill off MultiWayIf.
>
>
>
> But I don’t feel strongly.  If a consensus does not emerge, maybe we
> should just vote.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 17 September 2020 15:53
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of`
>
>
>
> Cale's rationale chimes with me. A lot - I feel like I might have even
> made the same point in previous threads on this. I think of the tradeoff
> like this:
>
>
>
> * The lack of \of doesn't really hurt very much. In fact, arguably by
> forcing the author to type some more characters and give something a name,
> we get code that's clearer for the reader. (yes this is very subjective,
> but syntax is).
>
> * The addition of \of *would* hurt new users of the language. Only a bit,
> but every bit makes things worse, and things are already quite bad.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg <rae at richarde.dev> wrote:
>
> Hi all,
>
> Proposal #302 was submitted to the committee and assigned to Cale. He has
> made a recommendation on the GitHub trail, but I don't believe the
> committee has discussed this among ourselves.
>
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199745852&sdata=dTBwWAv4oSLAVZXcCimFWfeNygnz%2FKcadcWw0YNdcuk%3D&reserved=0>
> Proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MusKqbiaRHp2rbPuyFQTYYiSP9%2FjGkwKKmPoPwRu1qc%3D&reserved=0>
> Cale's recommendation:
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-666075014&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MiDN5T22uVYITKYiB3yyyqrhe%2FleEKLvJk%2FjnaiVI7Y%3D&reserved=0>
>
> The idea, in brief, is to introduce a new syntax (guarded behind
> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>
> mplus :: Maybe Int -> Maybe Int -> Maybe Int
> mplus = \of
>   Nothing _ -> Nothing
>   _ Nothing -> Nothing
>   (Just x) (Just y) -> Just (x + y)
>
> The new keyword allows us to use a syntax similar to function definitions,
> but without repeating the name of the function. It is also like \case, but
> it allows multiple arguments. Guards are allowed, as usual.
>
> I really like this new syntax -- mostly because I find it very strange
> that we have to repeat the function name on every line. And then change the
> spacing when we change the function name. And I like the mnemonic "lambda
> of". And it allows me to write a where clause that is accessible in
> multiple different patterns, or an indented where clause that is usable in
> just one. If it didn't confuse readers, I would use this syntax all the
> time.
>
> Even so, I agree with Cale's recommendation to reject. We just have too
> much syntax! If someone were to come along and draft a concrete proposal of
> how we could, for example, use this syntax to replace both \case and if|,
> with a migration strategy, etc., then I might be in favor. Until then, I
> think we've spent our budget for cute, obscure bits of syntax.
>
> Richard
> _______________________________________________
> 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199765841&sdata=zraLb1BkWyd7RIDmN7GR%2B5IUJwzbetShFqcsp4RwLGQ%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200917/a2d3bdd4/attachment.html>

From rae at richarde.dev  Fri Sep 18 18:40:01 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 18 Sep 2020 18:40:01 +0000
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
 arrows
In-Reply-To: <CAH6fHQ=aBHaUK2S8cvxuJevd_LytW7WaT0bLW2XG=iG5U7f6ZQ@mail.gmail.com>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
 <dfb1fb4549609bcf6463fe85b8e5d4f9b924cf2b.camel@joachim-breitner.de>
 <CAH6fHQ=aBHaUK2S8cvxuJevd_LytW7WaT0bLW2XG=iG5U7f6ZQ@mail.gmail.com>
Message-ID: <010f0174a2841ca2-b1838f43-d066-45c5-9cf9-9fce9866266e-000000@us-east-2.amazonses.com>

Argh. Of the people who responded, 2 voted for % and 2 voted for ^. No one has voted to reject the proposal.

I thus declare the proposal accepted. But with what syntax? I have no conflict with a particular choice of glyph, so I will cast the tie-breaking vote for %. Rationale: ^1 is easy to believe as an exponentiation operator, whereas % has no tradition (within Haskell) as being used as a numerical infix operator.

The acceptance of the proposal gets the gears unblocked. If anyone feels this decision premature (or otherwise wrong), please do bleat, as we still have time to change the choice of glyph.

Happy Friday,
Richard

> On Sep 15, 2020, at 2:57 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> After looking at the renderings in https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690221468 <https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690221468> , I do prefer `^` over `%`. Not very strongly either.
> 
> On Mon, Sep 14, 2020 at 6:23 PM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> How annoying, how can I now say “I’m trusting the shepherd’s
> judgement” … ;-)
> 
> I guess in that case I’ll say I’m trusting Simon PJ, and will go with
> his vote, as I have no strong opinion of my own.
> 
> Cheers,
> Joachim
> 
> 
> Am Sonntag, den 13.09.2020, 22:12 +0000 schrieb Richard Eisenberg:
> > Hi committee,
> > 
> > Mathieu Boespflug has proposed a new syntax for linear arrows: https://github.com/ghc-proposals/ghc-proposals/pull/356 <https://github.com/ghc-proposals/ghc-proposals/pull/356>
> > 
> > Currently (from the original linear types proposal), we have #-> to denote a linear function, and # m -> to denote an arbitrary function whose argument has multiplicity m. This proposal suggests three changes:
> > 
> > 1. Drop #-> entirely.
> > 2. Use ^ instead of # in the second form, but require that it be a *prefix* usage of ^ (that is, the character after the ^ must not be  whitespace).
> > 3. Introduce a new lexeme ^1 that is used to denote linear functions.
> > Alternative: use % in place of ^; % is observed to be more visually apparent in some fonts than ^.
> > 
> > In time, the hope is that rule (3) will no longer be needed, if we gain overloaded numbers at the type level (when 1 :: Multiplicity will type-check without a special rule).
> > 
> > Motivations for this change come from the experience within Tweag of using linear types. The change away from # also is to avoid a conflict with overloaded labels, once those are allowed in types.
> > 
> > The hope is that we can make a decision about this in time for release with GHC 9.0. This proposal is already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020>
> > 
> > In conflict with our usual protocol, I will not make a recommendation on this proposal, as I am conflicted with the proposer. However, I do hope that we can come to a conclusion on this quickly, to avoid making a backward-incompatible change after a release.
> > 
> > We have four options:
> > A. Keep the syntax as it is.
> > B. Choose to go with ^
> > C. Choose to go with %
> > D. Choose to go with some other symbol. I don't think there is any particular preference for any one symbol over another.
> > 
> > Richard
> > _______________________________________________
> > 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>
> -- 
> 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
> 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/20200918/4098c89c/attachment.html>

From rae at richarde.dev  Fri Sep 18 19:44:12 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 18 Sep 2020 19:44:12 +0000
Subject: [ghc-steering-committee] The 'Char' kind
Message-ID: <010f0174a2bedf83-cbb3d9ce-fd93-44a6-a652-46002fc3c6df-000000@us-east-2.amazonses.com>

Hi GHCSC,

Before this committee existed, Alex Vieth submitted #11342 (https://gitlab.haskell.org/ghc/ghc/-/issues/11342 <https://gitlab.haskell.org/ghc/ghc/-/issues/11342>), requesting a kind `Char`. Serokell has now provided a patch, !3598 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598>). The chair of the CLC has signed off on this patch (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231>). But I feel we should, too.

What is a good process here? Just debate amongst ourselves? Post a GitHub Issue to call wider attention? Post a proposal? Merge without debate?

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

From iavor.diatchki at gmail.com  Fri Sep 18 20:08:44 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 18 Sep 2020 13:08:44 -0700
Subject: [ghc-steering-committee] Proposal #356: new syntax for linear
	arrows
In-Reply-To: <010f0174a2841ca2-b1838f43-d066-45c5-9cf9-9fce9866266e-000000@us-east-2.amazonses.com>
References: <010f017489868122-371537b8-be79-4e28-957b-36ee9be77e7c-000000@us-east-2.amazonses.com>
 <dfb1fb4549609bcf6463fe85b8e5d4f9b924cf2b.camel@joachim-breitner.de>
 <CAH6fHQ=aBHaUK2S8cvxuJevd_LytW7WaT0bLW2XG=iG5U7f6ZQ@mail.gmail.com>
 <010f0174a2841ca2-b1838f43-d066-45c5-9cf9-9fce9866266e-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nurm8EvKmJHae4gbyXbvEYSyg_=ZF9=j4J4GcR=c1sLE8A@mail.gmail.com>

I don't have an opinion on which to use, just FYI in Haskell `%` is used to
print and construct Rational numbers.

On Fri, Sep 18, 2020 at 11:40 AM Richard Eisenberg <rae at richarde.dev> wrote:

> Argh. Of the people who responded, 2 voted for % and 2 voted for ^. No one
> has voted to reject the proposal.
>
> I thus declare the proposal accepted. But with what syntax? I have no
> conflict with a particular choice of glyph, so I will cast the tie-breaking
> vote for %. Rationale: ^1 is easy to believe as an exponentiation operator,
> whereas % has no tradition (within Haskell) as being used as a numerical
> infix operator.
>
> The acceptance of the proposal gets the gears unblocked. If anyone feels
> this decision premature (or otherwise wrong), please do bleat, as we still
> have time to change the choice of glyph.
>
> Happy Friday,
> Richard
>
> On Sep 15, 2020, at 2:57 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> After looking at the renderings in
> https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690221468
> , I do prefer `^` over `%`. Not very strongly either.
>
> On Mon, Sep 14, 2020 at 6:23 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> How annoying, how can I now say “I’m trusting the shepherd’s
>> judgement” … ;-)
>>
>> I guess in that case I’ll say I’m trusting Simon PJ, and will go with
>> his vote, as I have no strong opinion of my own.
>>
>> Cheers,
>> Joachim
>>
>>
>> Am Sonntag, den 13.09.2020, 22:12 +0000 schrieb Richard Eisenberg:
>> > Hi committee,
>> >
>> > Mathieu Boespflug has proposed a new syntax for linear arrows:
>> https://github.com/ghc-proposals/ghc-proposals/pull/356
>> >
>> > Currently (from the original linear types proposal), we have #-> to
>> denote a linear function, and # m -> to denote an arbitrary function whose
>> argument has multiplicity m. This proposal suggests three changes:
>> >
>> > 1. Drop #-> entirely.
>> > 2. Use ^ instead of # in the second form, but require that it be a
>> *prefix* usage of ^ (that is, the character after the ^ must not be
>> whitespace).
>> > 3. Introduce a new lexeme ^1 that is used to denote linear functions.
>> > Alternative: use % in place of ^; % is observed to be more visually
>> apparent in some fonts than ^.
>> >
>> > In time, the hope is that rule (3) will no longer be needed, if we gain
>> overloaded numbers at the type level (when 1 :: Multiplicity will
>> type-check without a special rule).
>> >
>> > Motivations for this change come from the experience within Tweag of
>> using linear types. The change away from # also is to avoid a conflict with
>> overloaded labels, once those are allowed in types.
>> >
>> > The hope is that we can make a decision about this in time for release
>> with GHC 9.0. This proposal is already implemented:
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020
>> >
>> > In conflict with our usual protocol, I will not make a recommendation
>> on this proposal, as I am conflicted with the proposer. However, I do hope
>> that we can come to a conclusion on this quickly, to avoid making a
>> backward-incompatible change after a release.
>> >
>> > We have four options:
>> > A. Keep the syntax as it is.
>> > B. Choose to go with ^
>> > C. Choose to go with %
>> > D. Choose to go with some other symbol. I don't think there is any
>> particular preference for any one symbol over another.
>> >
>> > Richard
>> > _______________________________________________
>> > 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/
>>
>>
>> _______________________________________________
>> 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/20200918/f241b373/attachment-0001.html>

From simonpj at microsoft.com  Mon Sep 21 08:35:55 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Sep 2020 08:35:55 +0000
Subject: [ghc-steering-committee] The 'Char' kind
In-Reply-To: <010f0174a2bedf83-cbb3d9ce-fd93-44a6-a652-46002fc3c6df-000000@us-east-2.amazonses.com>
References: <010f0174a2bedf83-cbb3d9ce-fd93-44a6-a652-46002fc3c6df-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB042999E483F08D139729BD34AD3A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Thanks for alerting us.

If it was a few dozen lines I'd wave it through. But this is a 1800-line patch.   I've commented on the MR.

As to process, it sounds like a library issue, but it affects GHC's code base, and quite substantially so.  So I wonder if it might actually be salutary to write a proposal. At the same time I don't want to appear to discourage, still less sandbag, this as a contribution to GHC.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 18 September 2020 20:44
To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] The 'Char' kind

Hi GHCSC,

Before this committee existed, Alex Vieth submitted #11342 (https://gitlab.haskell.org/ghc/ghc/-/issues/11342<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11342&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746873922&sdata=NnGZFdf3tP5F93OiKvcZmYrQrRykZ4wixXQ%2FU9xiFIA%3D&reserved=0>), requesting a kind `Char`. Serokell has now provided a patch, !3598 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3598&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746873922&sdata=sM%2BmZ%2FXPGQ8RHxlioFtiUpcw3FBfrQogfnIEudEqhqM%3D&reserved=0>). The chair of the CLC has signed off on this patch (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3598%23note_300231&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746883879&sdata=XHCCmKT1i0DEfFBldTtKlQdHtDt%2F4s%2BuSlMt4HhAE%2Fk%3D&reserved=0>). But I feel we should, too.

What is a good process here? Just debate amongst ourselves? Post a GitHub Issue to call wider attention? Post a proposal? Merge without debate?

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

From iavor.diatchki at gmail.com  Mon Sep 21 16:17:23 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 21 Sep 2020 09:17:23 -0700
Subject: [ghc-steering-committee] The 'Char' kind
In-Reply-To: <VI1PR83MB042999E483F08D139729BD34AD3A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <010f0174a2bedf83-cbb3d9ce-fd93-44a6-a652-46002fc3c6df-000000@us-east-2.amazonses.com>
 <VI1PR83MB042999E483F08D139729BD34AD3A0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nup0q8L9FCOGrCJ4hpYayBkYG_OCJPpwiSE6uZD-hGAbZw@mail.gmail.com>

Presumably the patch contains some documentation in the GHC reference
manual?  I think that and the ticket would probably contain enough
information that one could put together into a proposal, and I think we
should encourage that, as at least we'd have all proposals documented in a
single place.

On Mon, Sep 21, 2020 at 1:36 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Thanks for alerting us.
>
>
>
> If it was a few dozen lines I’d wave it through. But this is a 1800-line
> patch.   I’ve commented on the MR.
>
>
>
> As to process, it sounds like a library issue, but it affects GHC’s code
> base, and quite substantially so.  So I wonder if it might actually be
> salutary to write a proposal. At the same time I don’t want to appear to
> discourage, still less sandbag, this as a contribution to GHC.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 18 September 2020 20:44
> *To:* Simon Peyton Jones via ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> *Subject:* [ghc-steering-committee] The 'Char' kind
>
>
>
> Hi GHCSC,
>
>
>
> Before this committee existed, Alex Vieth submitted #11342 (
> https://gitlab.haskell.org/ghc/ghc/-/issues/11342
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11342&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746873922&sdata=NnGZFdf3tP5F93OiKvcZmYrQrRykZ4wixXQ%2FU9xiFIA%3D&reserved=0>),
> requesting a kind `Char`. Serokell has now provided a patch, !3598 (
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3598&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746873922&sdata=sM%2BmZ%2FXPGQ8RHxlioFtiUpcw3FBfrQogfnIEudEqhqM%3D&reserved=0>).
> The chair of the CLC has signed off on this patch (
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3598%23note_300231&data=02%7C01%7Csimonpj%40microsoft.com%7C23e434cc47e14de9ce4708d85c0b3f5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360551746883879&sdata=XHCCmKT1i0DEfFBldTtKlQdHtDt%2F4s%2BuSlMt4HhAE%2Fk%3D&reserved=0>).
> But I feel we should, too.
>
>
>
> What is a good process here? Just debate amongst ourselves? Post a GitHub
> Issue to call wider attention? Post a proposal? Merge without debate?
>
>
>
> 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/20200921/2f277786/attachment.html>

From mail at joachim-breitner.de  Fri Sep 25 14:06:28 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 25 Sep 2020 16:06:28 +0200
Subject: [ghc-steering-committee] Please review #364: Unify Nat and Natural,
 Shepherd: Alejandro
Message-ID: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Unify Nat and Natural
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/364
https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst

I’ll propose Alejandro 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/



From rae at richarde.dev  Tue Sep 29 14:29:43 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 29 Sep 2020 14:29:43 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
Message-ID: <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!
Richard

> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:
> The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning.
> 
> New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.)
> 
> The extensions complement the design of standard Haskell. (This one seems the most subjective.)
> 
> The extension has been -- and can reasonably be predicted to remain -- stable.
> 
> The extension is not to gate-keep an advanced or potentially-unsafe feature.
> 
> The extension is widely-used.
> For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?
> 
> Alejandro
> 
> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com <mailto:marlowsd at gmail.com>>) escribió:
> I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.
> 
> Cheers
> Simon
> 
> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.
> 
> So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.
> 
> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?
> 
> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 <https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020>
> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
> I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.
> 
> Regards,
> Alejandro
> 
> 
> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io <mailto:eric at seidel.io>>) escribió:
> I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. 
> 
> I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?
> 
> This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.
> 
> Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. 
> 
> Eric
> 
> Sent from my iPhone
> 
>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> 
>> 
>> Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should
>> 
>> establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
>> express open-ness to a proposal, and then
>> review proposals when/if they materialise.
>>  
>> 
>> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. 
>> 
>>  
>> 
>> What do others think?
>> 
>>  
>> 
>> Simon
>> 
>>  
>> 
>> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> 
>> Sent: 08 September 2020 09:13
>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>> Cc: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>; Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> Subject: Re: [ghc-steering-committee] GHC 2020
>> 
>>  
>> 
>> Dear all,
>> 
>> I would really like to move this forward, and I would be happy to put some work on it.
>> 
>>  
>> 
>> What do you think of the following plan?
>> 
>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
>> 
>> - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.
>> 
>>  
>> 
>> If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>> 
>>  
>> 
>> Regards,
>> 
>> Alejandro
>> 
>>  
>> 
>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>) escribió:
>> 
>> Just back from holiday. Some thoughts
>> 
>> * I don’t think this mailing list is the best place for the
>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>   a committee member, possibly not) should write a proposal,
>>   and we should put it through the process.
>> 
>> * We should advertise the criteria, as Richard has done on the
>>   wiki page.
>> 
>> * Any such proposal should be informed by data. Notably, extension usage
>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>> 
>> * A proposer might also want to run a public poll, as an additional
>>   source of data
>> 
>> * When it comes to the committee, we can (I guess) vote on individual
>>   extensions, rather than just accept/reject the whole thing.
>> 
>> I am intrigued by the idea of using Kialo to coordinate discussion.
>> Maybe it'd work better than GitHub?  Are there other alternatives?
>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>> 
>> 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: 02 September 2020 14:57
>> |  To: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
>> |  Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>> |  
>> |  It seems clear that my wiki idea isn't winning the day -- I never
>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>> |  approach is that it seems hard to get good community involvement.
>> |  
>> |  Richard
>> |  
>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>> |  >
>> |  > Opening a regular discussion about whether and how we want to work on
>> |  GHC 2020 sounds fine, that will also give the community a place to
>> |  weigh in. I do think the eventual contents should be informed by the
>> |  community though, it shouldn’t just be us working alone.
>> |  >
>> |  > Sent from my iPhone
>> |  >
>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>> |  breitner.de <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>> wrote:
>> |  >>
>> |  >> Hi,
>> |  >>
>> |  >> sounds plausible. It would also allow us to use tags to easily
>> |  indicate
>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
>> |  >> then filter by issue to get the current list…
>> |  >>
>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>> |  on
>> |  >>
>> |  >> * do we even want that?
>> |  >> * what are the abstract criteria (or guidelines)?
>> |  >> * what is the process?
>> |  >>
>> |  >> I believe that discussion could be done like any other proposal.
>> |  >>
>> |  >>
>> |  >> As for the process; when I brought up the idea, I was worried about
>> |  us
>> |  >> spending huge resources discussion individual extensions to death,
>> |  and
>> |  >> proposed, in the interest of efficiency and getting things done:
>> |  >>
>> |  >>> The process could be: Every member can nominate any number of
>> |  >>> extensions, to include, maybe a small rationale and then we do one
>> |  >>> round of independent approval voting, requiring a supermajority to
>> |  >>> really only pick uncontested extensions.
>> |  >>
>> |  >> So instead of long debates, we start with GHC2020 being just those
>> |  >> extensions that a supermajority on the committee considers to be ok.
>> |  >>
>> |  >> This is much more lightweight process that we could get done in a
>> |  week
>> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
>> |  >> out one or two extension that initially people are reserved about,
>> |  but
>> |  >> could be swayed after lengthy discussions. But is that worth the
>> |  >> lengthy discussion?
>> |  >>
>> |  >> 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.jo <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo>
>> |  achim-
>> |  breitner.de <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>%7Cfa6e3a6bcdf
>> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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>
> _______________________________________________
> 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/20200929/c07f4c89/attachment-0001.html>

From trupill at gmail.com  Tue Sep 29 14:50:53 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 29 Sep 2020 16:50:53 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>

I am still happy to drive this! I was not sure about whether we agreed as a
Committee on pushing this.

To make this more actionable, my goal is, *during next Sunday*, to create a
new proposal with the *criteria* (based on Richard + Simon's list), and a
preliminary assessment of which of the *current extensions* satisfy these
criteria, and for those we might be willing to grant *exceptions*.

Please raise your voice if you think we should proceed otherwise (or if you
think we should not proceed at all!).

Regards,
Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> What's the status of this push? I was delighted to see that Alejandro
> volunteered to be a motive force on this idea, and have thus refrained (as
> I am pushing on other ideas, too). But I also don't want this to die. :)
>
> Thanks!
> Richard
>
> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> I agree with using the criteria that Richard posted + the addition by
> Simon. Just in case somebody hadn't looked at the wiki, the criteria would
> be:
>
>    1.
>
>    The extension is (mostly) conservative: All programs that were
>    accepted without the extension remain accepted, and with the same meaning.
>    2.
>
>    New failure modes that become possible with the extension are rare
>    and/or easy to diagnose. (These failure modes include new error messages,
>    wrong inferred types, and runtime errors, for example.)
>    3.
>
>    The extensions complement the design of standard Haskell. (This one
>    seems the most subjective.)
>    4.
>
>    The extension has been -- and can reasonably be predicted to remain --
>    stable.
>    5.
>
>    The extension is not to gate-keep an advanced or potentially-unsafe
>    feature.
>    6. The extension is widely-used.
>
> For example, should we add to (6) "in current developments"? What about
> things like "EmptyDataDecls", which are just straightforward
> generalizations of what Haskell 2010 already allows, although in practice
> the only data type you would ever need to be empty is "Void"?
>
> Alejandro
>
> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
> escribió:
>
>> I think there should be some requirement that an extension be widely-used
>> (for some suitable definition of that), before we ratify it in GHC2020.
>> Some of the extensions that made it past the first round of filtering are
>> not widely-used, and would be therefore probably be controversial additions
>> to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
>> to name a few that I noticed straight off. I think it's a good idea to be
>> conservative here.
>>
>> Cheers
>> Simon
>>
>> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> There seems to be some question about who should drive this debate. But
>>> there is something we all seem to agree on: it is our role, as the steering
>>> committee, to announce the criteria by which we intend to judge the
>>> reasonableness of each potential candidate extension.
>>>
>>> So, let me suggest that we start discussing that, and move back to how
>>> this discussion ought to be driven when we are a bit clearer on the
>>> criteria.
>>>
>>> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
>>> that they are worthy of discussion. So let me ask the question: do we agree
>>> with all these criteria? do we want to add more?
>>>
>>> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>>>
>>> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <
>>> trupill at gmail.com> wrote:
>>>
>>>> I would rather make the process Committee-driven, because otherwise it
>>>> may derail into too many micro-discussions. I think it's better to start a
>>>> conversation saying "this is our proposal, here are our criteria, here are
>>>> the exceptions we want to make", and then discuss from there.
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>>
>>>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>>>> escribió:
>>>>
>>>>> I think we may want to have the Committee initiate and drive the
>>>>> process. I think a GHC20XX proposal will turn into a bunch of micro
>>>>> proposals and discussions about individual (groups of) extensions, and it
>>>>> will be hard to track all of the threads of discussion in a single GitHub
>>>>> thread. We’ve dealt with long and contentious discussions before, but they
>>>>> were much more focused than GHC20XX will be, by design.
>>>>>
>>>>> I suggested earlier that an alternative strategy could be to open a
>>>>> new repo where the community can collaborate on GHC20XX via a familiar
>>>>> PR-based process, with each proposed group of extensions getting its own PR
>>>>> and discussion. There are a few open questions here though. When/how do we
>>>>> decide that it’s time for a new standard? How do we decide when the full
>>>>> proposal is ready for review? Do we need to review and sign off on each
>>>>> group of extensions separately or only the final product?
>>>>>
>>>>> This process would be a lot more work for us, so I’m happy to try the
>>>>> usual process first, and I’ll be happy to be proved wrong. But we should be
>>>>> prepared to step in and add some more structure if needed.
>>>>>
>>>>> Regardless, the first step should be to update our docs to express
>>>>> interest in GHC20XX proposals, establish criteria for including language
>>>>> extensions, and outline a process for submitting them.
>>>>>
>>>>> Eric
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>>>>> wrote:
>>>>>
>>>>> 
>>>>>
>>>>> Personally I don’t think we should make the Steering Committee
>>>>> responsible for initiating or driving this.  We should
>>>>>
>>>>>    - establish the criteria (including some idea of how frequently
>>>>>    we’d be open to creating a new GHCxx version),
>>>>>    - express open-ness to a proposal, and then
>>>>>    - review proposals when/if they materialise.
>>>>>
>>>>>
>>>>>
>>>>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>>>>> that’s different from making the committee *responsible*.
>>>>>
>>>>>
>>>>>
>>>>> What do others think?
>>>>>
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>> *Sent:* 08 September 2020 09:13
>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <
>>>>> eric at seidel.io>; ghc-steering-committee at haskell.org
>>>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I would really like to move this forward, and I would be happy to put
>>>>> some work on it.
>>>>>
>>>>>
>>>>>
>>>>> What do you think of the following plan?
>>>>>
>>>>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>>>>> think the criteria in the wiki are quite nice. Explain that one of the
>>>>> goals is to encompass as many stable extensions as possible.
>>>>>
>>>>> - Reformat the list to make 3 tables: one for extensions which satisfy
>>>>> all 5 criteria, one for extensions we want to include even if they don't,
>>>>> and one for those which should be rejected in the light of those criteria.
>>>>>
>>>>>
>>>>>
>>>>> If the process works well, we could think about instaurating a
>>>>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alejandro
>>>>>
>>>>>
>>>>>
>>>>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>>>>> ghc-steering-committee (<ghc-steering-committee at haskell.org>)
>>>>> escribió:
>>>>>
>>>>> Just back from holiday. Some thoughts
>>>>>
>>>>> * I don’t think this mailing list is the best place for the
>>>>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>>>>   a committee member, possibly not) should write a proposal,
>>>>>   and we should put it through the process.
>>>>>
>>>>> * We should advertise the criteria, as Richard has done on the
>>>>>   wiki page.
>>>>>
>>>>> * Any such proposal should be informed by data. Notably, extension
>>>>> usage
>>>>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>>>>
>>>>> * A proposer might also want to run a public poll, as an additional
>>>>>   source of data
>>>>>
>>>>> * When it comes to the committee, we can (I guess) vote on individual
>>>>>   extensions, rather than just accept/reject the whole thing.
>>>>>
>>>>> I am intrigued by the idea of using Kialo to coordinate discussion.
>>>>> Maybe it'd work better than GitHub?  Are there other alternatives?
>>>>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>>>>
>>>>> Simon
>>>>>
>>>>> |  -----Original Message-----
>>>>> |  From: ghc-steering-committee <ghc-steering-committee-
>>>>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>>>>> |  Sent: 02 September 2020 14:57
>>>>> |  To: Eric Seidel <eric at seidel.io>
>>>>> |  Cc: ghc-steering-committee at haskell.org
>>>>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>>>>> |
>>>>> |  It seems clear that my wiki idea isn't winning the day -- I never
>>>>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>>>>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>>>>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>>>>> |  approach is that it seems hard to get good community involvement.
>>>>> |
>>>>> |  Richard
>>>>> |
>>>>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>>>>> |  >
>>>>> |  > Opening a regular discussion about whether and how we want to
>>>>> work on
>>>>> |  GHC 2020 sounds fine, that will also give the community a place to
>>>>> |  weigh in. I do think the eventual contents should be informed by the
>>>>> |  community though, it shouldn’t just be us working alone.
>>>>> |  >
>>>>> |  > Sent from my iPhone
>>>>> |  >
>>>>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>>>>> |  breitner.de
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
>>>>> wrote:
>>>>> |  >>
>>>>> |  >> Hi,
>>>>> |  >>
>>>>> |  >> sounds plausible. It would also allow us to use tags to easily
>>>>> |  indicate
>>>>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…),
>>>>> and
>>>>> |  >> then filter by issue to get the current list…
>>>>> |  >>
>>>>> |  >> But before we go there, shouldn’t we maybe have a discussion
>>>>> first
>>>>> |  on
>>>>> |  >>
>>>>> |  >> * do we even want that?
>>>>> |  >> * what are the abstract criteria (or guidelines)?
>>>>> |  >> * what is the process?
>>>>> |  >>
>>>>> |  >> I believe that discussion could be done like any other proposal.
>>>>> |  >>
>>>>> |  >>
>>>>> |  >> As for the process; when I brought up the idea, I was worried
>>>>> about
>>>>> |  us
>>>>> |  >> spending huge resources discussion individual extensions to
>>>>> death,
>>>>> |  and
>>>>> |  >> proposed, in the interest of efficiency and getting things done:
>>>>> |  >>
>>>>> |  >>> The process could be: Every member can nominate any number of
>>>>> |  >>> extensions, to include, maybe a small rationale and then we do
>>>>> one
>>>>> |  >>> round of independent approval voting, requiring a supermajority
>>>>> to
>>>>> |  >>> really only pick uncontested extensions.
>>>>> |  >>
>>>>> |  >> So instead of long debates, we start with GHC2020 being just
>>>>> those
>>>>> |  >> extensions that a supermajority on the committee considers to be
>>>>> ok.
>>>>> |  >>
>>>>> |  >> This is much more lightweight process that we could get done in a
>>>>> |  week
>>>>> |  >> or two (maybe using a doodle-like voting page). Maybe we would
>>>>> leave
>>>>> |  >> out one or two extension that initially people are reserved
>>>>> about,
>>>>> |  but
>>>>> |  >> could be swayed after lengthy discussions. But is that worth the
>>>>> |  >> lengthy discussion?
>>>>> |  >>
>>>>> |  >> cheers,
>>>>> |  >> Joachim
>>>>> |  >>
>>>>> |  >> --
>>>>> |  >> Joachim Breitner
>>>>> |  >> mail at joachim-breitner.de
>>>>> |  >>
>>>>> |
>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>>>>> |  achim-
>>>>> |  breitner.de
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
>>>>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf
>>>>> |
>>>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>>>> |
>>>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%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
>>>>
>>> _______________________________________________
>>> 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/20200929/b1f1b5d7/attachment-0001.html>

From rae at richarde.dev  Tue Sep 29 15:00:54 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 29 Sep 2020 15:00:54 +0000
Subject: [ghc-steering-committee] Steering Committee bylaws
Message-ID: <010f0174da61781d-6475f729-63d4-4880-8c26-a0d22a85cc29-000000@us-east-2.amazonses.com>

Hi all,

Some time ago, I posted https://github.com/ghc-proposals/ghc-proposals/pull/360 <https://github.com/ghc-proposals/ghc-proposals/pull/360>, an attempt at crafting bylaws for this committee. Conversation has died down, and so I'd like to have a discussion that will lead to amendments and then eventual acceptance (of something).

I think it's best for this discussion to be right on the PR, not this thread. However, given that this PR is all about how we function, as a committee, I would like to see participation (ideally, agreement!) from everyone here before proceeding, even if it's just a LGTM.

Thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200929/81f3aa75/attachment.html>

From trupill at gmail.com  Tue Sep 29 15:21:45 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 29 Sep 2020 17:21:45 +0200
Subject: [ghc-steering-committee] Steering Committee bylaws
In-Reply-To: <010f0174da61781d-6475f729-63d4-4880-8c26-a0d22a85cc29-000000@us-east-2.amazonses.com>
References: <010f0174da61781d-6475f729-63d4-4880-8c26-a0d22a85cc29-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtQZhQM60+eak8WVVWr615k56hkguTwSeC8J+OFWMbRbg@mail.gmail.com>

LGTM.

El mar., 29 sept. 2020 a las 17:01, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> Hi all,
>
> Some time ago, I posted
> https://github.com/ghc-proposals/ghc-proposals/pull/360, an attempt at
> crafting bylaws for this committee. Conversation has died down, and so I'd
> like to have a discussion that will lead to amendments and then eventual
> acceptance (of something).
>
> I think it's best for this discussion to be right on the PR, not this
> thread. However, given that this PR is all about how we function, as a
> committee, I would like to see participation (ideally, agreement!) from
> everyone here before proceeding, even if it's just a LGTM.
>
> 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/20200929/8bd00c87/attachment.html>

From simonpj at microsoft.com  Tue Sep 29 16:05:48 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Sep 2020 16:05:48 +0000
Subject: [ghc-steering-committee] Steering Committee bylaws
In-Reply-To: <010f0174da61781d-6475f729-63d4-4880-8c26-a0d22a85cc29-000000@us-east-2.amazonses.com>
References: <010f0174da61781d-6475f729-63d4-4880-8c26-a0d22a85cc29-000000@us-east-2.amazonses.com>
Message-ID: <VI1PR83MB0429F54EBA66D6B0051226AAAD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>

It looks like a good draft to me; doubtless may get refined in the light of experience.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 29 September 2020 16:01
To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] Steering Committee bylaws

Hi all,

Some time ago, I posted https://github.com/ghc-proposals/ghc-proposals/pull/360<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F360&data=02%7C01%7Csimonpj%40microsoft.com%7Cf9610b49f9044d06b79808d864887eb9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369885297700231&sdata=XrWJuBKFKxQA%2B2UthwqeaW9ur7T56e01BW%2FzU%2FiGFiE%3D&reserved=0>, an attempt at crafting bylaws for this committee. Conversation has died down, and so I'd like to have a discussion that will lead to amendments and then eventual acceptance (of something).

I think it's best for this discussion to be right on the PR, not this thread. However, given that this PR is all about how we function, as a committee, I would like to see participation (ideally, agreement!) from everyone here before proceeding, even if it's just a LGTM.

Thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200929/5f7a7c7f/attachment.html>

From simonpj at microsoft.com  Tue Sep 29 16:06:48 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Sep 2020 16:06:48 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
Message-ID: <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>

OK by me.   Thank you

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 29 September 2020 15:51
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] GHC 2020

I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this.

To make this more actionable, my goal is, during next Sunday, to create a new proposal with the criteria (based on Richard + Simon's list), and a preliminary assessment of which of the current extensions satisfy these criteria, and for those we might be willing to grant exceptions.

Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!).

Regards,
Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev<mailto:rae at richarde.dev>>) escribió:
What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!
Richard


On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:

  1.  The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning.
  2.  New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.)
  3.  The extensions complement the design of standard Haskell. (This one seems the most subjective.)
  4.  The extension has been -- and can reasonably be predicted to remain -- stable.
  5.  The extension is not to gate-keep an advanced or potentially-unsafe feature.
  6.  The extension is widely-used.
For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com<mailto:marlowsd at gmail.com>>) escribió:
I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers
Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:
There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:
I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards,
Alejandro


El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io<mailto:eric at seidel.io>>) escribió:
I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric
Sent from my iPhone


On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should
·         establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
·         express open-ness to a proposal, and then
·         review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible.

What do others think?

Simon

From: Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>>
Sent: 08 September 2020 09:13
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>; Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,
I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?
- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,
Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>) escribió:
Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the
  discussion.  Basically, it's a GHC Proposal, so someone (possibly
  a committee member, possibly not) should write a proposal,
  and we should put it through the process.

* We should advertise the criteria, as Richard has done on the
  wiki page.

* Any such proposal should be informed by data. Notably, extension usage
  in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional
  source of data

* When it comes to the committee, we can (I guess) vote on individual
  extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion.
Maybe it'd work better than GitHub?  Are there other alternatives?
But that's orthogonal to the GHC 2020 idea; let's not conflate them.

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: 02 September 2020 14:57
|  To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
|  Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  Subject: Re: [ghc-steering-committee] GHC 2020
|
|  It seems clear that my wiki idea isn't winning the day -- I never
|  really liked it either. I'd be fine with either Eric's or Joachim's
|  approaches. Maybe start with Joachim's approach and then use Eric's
|  when Joachim's runs out of steam? A big minus, though, to Joachim's
|  approach is that it seems hard to get good community involvement.
|
|  Richard
|
|  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
|  >
|  > Opening a regular discussion about whether and how we want to work on
|  GHC 2020 sounds fine, that will also give the community a place to
|  weigh in. I do think the eventual contents should be informed by the
|  community though, it shouldn’t just be us working alone.
|  >
|  > Sent from my iPhone
|  >
|  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
|  breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>> wrote:
|  >>
|  >> Hi,
|  >>
|  >> sounds plausible. It would also allow us to use tags to easily
|  indicate
|  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
|  >> then filter by issue to get the current list…
|  >>
|  >> But before we go there, shouldn’t we maybe have a discussion first
|  on
|  >>
|  >> * do we even want that?
|  >> * what are the abstract criteria (or guidelines)?
|  >> * what is the process?
|  >>
|  >> I believe that discussion could be done like any other proposal.
|  >>
|  >>
|  >> As for the process; when I brought up the idea, I was worried about
|  us
|  >> spending huge resources discussion individual extensions to death,
|  and
|  >> proposed, in the interest of efficiency and getting things done:
|  >>
|  >>> The process could be: Every member can nominate any number of
|  >>> extensions, to include, maybe a small rationale and then we do one
|  >>> round of independent approval voting, requiring a supermajority to
|  >>> really only pick uncontested extensions.
|  >>
|  >> So instead of long debates, we start with GHC2020 being just those
|  >> extensions that a supermajority on the committee considers to be ok.
|  >>
|  >> This is much more lightweight process that we could get done in a
|  week
|  >> or two (maybe using a doodle-like voting page). Maybe we would leave
|  >> out one or two extension that initially people are reserved about,
|  but
|  >> could be swayed after lengthy discussions. But is that worth the
|  >> lengthy discussion?
|  >>
|  >> 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.jo
|  achim-
|  breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>%7Cfa6e3a6bcdf
|  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0>

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

From iavor.diatchki at gmail.com  Tue Sep 29 16:38:07 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 29 Sep 2020 09:38:07 -0700
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>

Thanks Alejandro.  My preference would be that you share whatever you come
up with the list so we can discuss it, before making a proposal that would
represent the committee.
-Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> OK by me.   Thank you
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 29 September 2020 15:51
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> I am still happy to drive this! I was not sure about whether we agreed as
> a Committee on pushing this.
>
>
>
> To make this more actionable, my goal is, *during next Sunday*, to create
> a new proposal with the *criteria* (based on Richard + Simon's list), and
> a preliminary assessment of which of the *current extensions* satisfy
> these criteria, and for those we might be willing to grant *exceptions*.
>
>
>
> Please raise your voice if you think we should proceed otherwise (or if
> you think we should not proceed at all!).
>
>
>
> Regards,
>
> Alejandro
>
>
>
> El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
> What's the status of this push? I was delighted to see that Alejandro
> volunteered to be a motive force on this idea, and have thus refrained (as
> I am pushing on other ideas, too). But I also don't want this to die. :)
>
>
>
> Thanks!
>
> Richard
>
>
>
> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>
>
> I agree with using the criteria that Richard posted + the addition by
> Simon. Just in case somebody hadn't looked at the wiki, the criteria would
> be:
>
>    1. The extension is (mostly) conservative: All programs that were
>    accepted without the extension remain accepted, and with the same meaning.
>    2. New failure modes that become possible with the extension are rare
>    and/or easy to diagnose. (These failure modes include new error messages,
>    wrong inferred types, and runtime errors, for example.)
>    3. The extensions complement the design of standard Haskell. (This one
>    seems the most subjective.)
>    4. The extension has been -- and can reasonably be predicted to remain
>    -- stable.
>    5. The extension is not to gate-keep an advanced or potentially-unsafe
>    feature.
>    6. The extension is widely-used.
>
> For example, should we add to (6) "in current developments"? What about
> things like "EmptyDataDecls", which are just straightforward
> generalizations of what Haskell 2010 already allows, although in practice
> the only data type you would ever need to be empty is "Void"?
>
>
>
> Alejandro
>
>
>
> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
> escribió:
>
> I think there should be some requirement that an extension be widely-used
> (for some suitable definition of that), before we ratify it in GHC2020.
> Some of the extensions that made it past the first round of filtering are
> not widely-used, and would be therefore probably be controversial additions
> to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
> to name a few that I noticed straight off. I think it's a good idea to be
> conservative here.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> There seems to be some question about who should drive this debate. But
> there is something we all seem to agree on: it is our role, as the steering
> committee, to announce the criteria by which we intend to judge the
> reasonableness of each potential candidate extension.
>
>
>
> So, let me suggest that we start discussing that, and move back to how
> this discussion ought to be driven when we are a bit clearer on the
> criteria.
>
>
>
> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
> that they are worthy of discussion. So let me ask the question: do we agree
> with all these criteria? do we want to add more?
>
>
>
> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>
>
>
>
> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> I would rather make the process Committee-driven, because otherwise it may
> derail into too many micro-discussions. I think it's better to start a
> conversation saying "this is our proposal, here are our criteria, here are
> the exceptions we want to make", and then discuss from there.
>
>
>
> Regards,
>
> Alejandro
>
>
>
>
>
> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
> escribió:
>
> I think we may want to have the Committee initiate and drive the process.
> I think a GHC20XX proposal will turn into a bunch of micro proposals and
> discussions about individual (groups of) extensions, and it will be hard to
> track all of the threads of discussion in a single GitHub thread. We’ve
> dealt with long and contentious discussions before, but they were much more
> focused than GHC20XX will be, by design.
>
>
>
> I suggested earlier that an alternative strategy could be to open a new
> repo where the community can collaborate on GHC20XX via a familiar PR-based
> process, with each proposed group of extensions getting its own PR and
> discussion. There are a few open questions here though. When/how do we
> decide that it’s time for a new standard? How do we decide when the full
> proposal is ready for review? Do we need to review and sign off on each
> group of extensions separately or only the final product?
>
>
>
> This process would be a lot more work for us, so I’m happy to try the
> usual process first, and I’ll be happy to be proved wrong. But we should be
> prepared to step in and add some more structure if needed.
>
>
>
> Regardless, the first step should be to update our docs to express
> interest in GHC20XX proposals, establish criteria for including language
> extensions, and outline a process for submitting them.
>
>
>
> Eric
>
> Sent from my iPhone
>
>
>
> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> 
>
> Personally I don’t think we should make the Steering Committee responsible
> for initiating or driving this.  We should
>
> ·         establish the criteria (including some idea of how frequently
> we’d be open to creating a new GHCxx version),
>
> ·         express open-ness to a proposal, and then
>
> ·         review proposals when/if they materialise.
>
>
>
> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s
> different from making the committee *responsible*.
>
>
>
> What do others think?
>
>
>
> Simon
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 08 September 2020 09:13
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
> ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> Dear all,
>
> I would really like to move this forward, and I would be happy to put some
> work on it.
>
>
>
> What do you think of the following plan?
>
> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
> think the criteria in the wiki are quite nice. Explain that one of the
> goals is to encompass as many stable extensions as possible.
>
> - Reformat the list to make 3 tables: one for extensions which satisfy all
> 5 criteria, one for extensions we want to include even if they don't, and
> one for those which should be rejected in the light of those criteria.
>
>
>
> If the process works well, we could think about instaurating a
> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>
> Just back from holiday. Some thoughts
>
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
>
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
>
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>
> * A proposer might also want to run a public poll, as an additional
>   source of data
>
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
>
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |
> |  Richard
> |
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>>
> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> cheers,
> |  >> Joachim
> |  >>
> |  >> --
> |  >> Joachim Breitner
> |  >> mail at joachim-breitner.de
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>
> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>
> %7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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/20200929/85460984/attachment-0001.html>

From trupill at gmail.com  Wed Sep 30 20:06:25 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 30 Sep 2020 22:06:25 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
Message-ID: <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>

Dear all,
I've started working on a proposal for GHC2020. You can see the current
status here:
https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md

I noticed the list by Richard was not exhaustive. Those extensions are
headed by "In discussion". Preferably we should make up our minds before
presenting the proposal. I would say there are three big groups of
proposals. Any feedback is welcome on that part.

Regards,
Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
iavor.diatchki at gmail.com>) escribió:

> Thanks Alejandro.  My preference would be that you share whatever you come
> up with the list so we can discuss it, before making a proposal that would
> represent the committee.
> -Iavor
>
> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> OK by me.   Thank you
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>> Serrano Mena
>> *Sent:* 29 September 2020 15:51
>> *To:* Richard Eisenberg <rae at richarde.dev>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>
>>
>>
>> I am still happy to drive this! I was not sure about whether we agreed as
>> a Committee on pushing this.
>>
>>
>>
>> To make this more actionable, my goal is, *during next Sunday*, to
>> create a new proposal with the *criteria* (based on Richard + Simon's
>> list), and a preliminary assessment of which of the *current extensions*
>> satisfy these criteria, and for those we might be willing to grant
>> *exceptions*.
>>
>>
>>
>> Please raise your voice if you think we should proceed otherwise (or if
>> you think we should not proceed at all!).
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev>)
>> escribió:
>>
>> What's the status of this push? I was delighted to see that Alejandro
>> volunteered to be a motive force on this idea, and have thus refrained (as
>> I am pushing on other ideas, too). But I also don't want this to die. :)
>>
>>
>>
>> Thanks!
>>
>> Richard
>>
>>
>>
>> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>>
>>
>> I agree with using the criteria that Richard posted + the addition by
>> Simon. Just in case somebody hadn't looked at the wiki, the criteria would
>> be:
>>
>>    1. The extension is (mostly) conservative: All programs that were
>>    accepted without the extension remain accepted, and with the same meaning.
>>    2. New failure modes that become possible with the extension are rare
>>    and/or easy to diagnose. (These failure modes include new error messages,
>>    wrong inferred types, and runtime errors, for example.)
>>    3. The extensions complement the design of standard Haskell. (This
>>    one seems the most subjective.)
>>    4. The extension has been -- and can reasonably be predicted to
>>    remain -- stable.
>>    5. The extension is not to gate-keep an advanced or
>>    potentially-unsafe feature.
>>    6. The extension is widely-used.
>>
>> For example, should we add to (6) "in current developments"? What about
>> things like "EmptyDataDecls", which are just straightforward
>> generalizations of what Haskell 2010 already allows, although in practice
>> the only data type you would ever need to be empty is "Void"?
>>
>>
>>
>> Alejandro
>>
>>
>>
>> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
>> escribió:
>>
>> I think there should be some requirement that an extension be widely-used
>> (for some suitable definition of that), before we ratify it in GHC2020.
>> Some of the extensions that made it past the first round of filtering are
>> not widely-used, and would be therefore probably be controversial additions
>> to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
>> to name a few that I noticed straight off. I think it's a good idea to be
>> conservative here.
>>
>>
>>
>> Cheers
>>
>> Simon
>>
>>
>>
>> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> There seems to be some question about who should drive this debate. But
>> there is something we all seem to agree on: it is our role, as the steering
>> committee, to announce the criteria by which we intend to judge the
>> reasonableness of each potential candidate extension.
>>
>>
>>
>> So, let me suggest that we start discussing that, and move back to how
>> this discussion ought to be driven when we are a bit clearer on the
>> criteria.
>>
>>
>>
>> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
>> that they are worthy of discussion. So let me ask the question: do we agree
>> with all these criteria? do we want to add more?
>>
>>
>>
>> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>
>>
>>
>>
>> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> I would rather make the process Committee-driven, because otherwise it
>> may derail into too many micro-discussions. I think it's better to start a
>> conversation saying "this is our proposal, here are our criteria, here are
>> the exceptions we want to make", and then discuss from there.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>>
>>
>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>> escribió:
>>
>> I think we may want to have the Committee initiate and drive the process.
>> I think a GHC20XX proposal will turn into a bunch of micro proposals and
>> discussions about individual (groups of) extensions, and it will be hard to
>> track all of the threads of discussion in a single GitHub thread. We’ve
>> dealt with long and contentious discussions before, but they were much more
>> focused than GHC20XX will be, by design.
>>
>>
>>
>> I suggested earlier that an alternative strategy could be to open a new
>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>> process, with each proposed group of extensions getting its own PR and
>> discussion. There are a few open questions here though. When/how do we
>> decide that it’s time for a new standard? How do we decide when the full
>> proposal is ready for review? Do we need to review and sign off on each
>> group of extensions separately or only the final product?
>>
>>
>>
>> This process would be a lot more work for us, so I’m happy to try the
>> usual process first, and I’ll be happy to be proved wrong. But we should be
>> prepared to step in and add some more structure if needed.
>>
>>
>>
>> Regardless, the first step should be to update our docs to express
>> interest in GHC20XX proposals, establish criteria for including language
>> extensions, and outline a process for submitting them.
>>
>>
>>
>> Eric
>>
>> Sent from my iPhone
>>
>>
>>
>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> 
>>
>> Personally I don’t think we should make the Steering Committee
>> responsible for initiating or driving this.  We should
>>
>> ·         establish the criteria (including some idea of how frequently
>> we’d be open to creating a new GHCxx version),
>>
>> ·         express open-ness to a proposal, and then
>>
>> ·         review proposals when/if they materialise.
>>
>>
>>
>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>> that’s different from making the committee *responsible*.
>>
>>
>>
>> What do others think?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>> *Sent:* 08 September 2020 09:13
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>> ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>
>>
>>
>> Dear all,
>>
>> I would really like to move this forward, and I would be happy to put
>> some work on it.
>>
>>
>>
>> What do you think of the following plan?
>>
>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>> think the criteria in the wiki are quite nice. Explain that one of the
>> goals is to encompass as many stable extensions as possible.
>>
>> - Reformat the list to make 3 tables: one for extensions which satisfy
>> all 5 criteria, one for extensions we want to include even if they don't,
>> and one for those which should be rejected in the light of those criteria.
>>
>>
>>
>> If the process works well, we could think about instaurating a
>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>
>> Just back from holiday. Some thoughts
>>
>> * I don’t think this mailing list is the best place for the
>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>   a committee member, possibly not) should write a proposal,
>>   and we should put it through the process.
>>
>> * We should advertise the criteria, as Richard has done on the
>>   wiki page.
>>
>> * Any such proposal should be informed by data. Notably, extension usage
>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>
>> * A proposer might also want to run a public poll, as an additional
>>   source of data
>>
>> * When it comes to the committee, we can (I guess) vote on individual
>>   extensions, rather than just accept/reject the whole thing.
>>
>> I am intrigued by the idea of using Kialo to coordinate discussion.
>> Maybe it'd work better than GitHub?  Are there other alternatives?
>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-steering-committee <ghc-steering-committee-
>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>> |  Sent: 02 September 2020 14:57
>> |  To: Eric Seidel <eric at seidel.io>
>> |  Cc: ghc-steering-committee at haskell.org
>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>> |
>> |  It seems clear that my wiki idea isn't winning the day -- I never
>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>> |  approach is that it seems hard to get good community involvement.
>> |
>> |  Richard
>> |
>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>> |  >
>> |  > Opening a regular discussion about whether and how we want to work on
>> |  GHC 2020 sounds fine, that will also give the community a place to
>> |  weigh in. I do think the eventual contents should be informed by the
>> |  community though, it shouldn’t just be us working alone.
>> |  >
>> |  > Sent from my iPhone
>> |  >
>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>> |  breitner.de
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>>
>> wrote:
>> |  >>
>> |  >> Hi,
>> |  >>
>> |  >> sounds plausible. It would also allow us to use tags to easily
>> |  indicate
>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
>> |  >> then filter by issue to get the current list…
>> |  >>
>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>> |  on
>> |  >>
>> |  >> * do we even want that?
>> |  >> * what are the abstract criteria (or guidelines)?
>> |  >> * what is the process?
>> |  >>
>> |  >> I believe that discussion could be done like any other proposal.
>> |  >>
>> |  >>
>> |  >> As for the process; when I brought up the idea, I was worried about
>> |  us
>> |  >> spending huge resources discussion individual extensions to death,
>> |  and
>> |  >> proposed, in the interest of efficiency and getting things done:
>> |  >>
>> |  >>> The process could be: Every member can nominate any number of
>> |  >>> extensions, to include, maybe a small rationale and then we do one
>> |  >>> round of independent approval voting, requiring a supermajority to
>> |  >>> really only pick uncontested extensions.
>> |  >>
>> |  >> So instead of long debates, we start with GHC2020 being just those
>> |  >> extensions that a supermajority on the committee considers to be ok.
>> |  >>
>> |  >> This is much more lightweight process that we could get done in a
>> |  week
>> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
>> |  >> out one or two extension that initially people are reserved about,
>> |  but
>> |  >> could be swayed after lengthy discussions. But is that worth the
>> |  >> lengthy discussion?
>> |  >>
>> |  >> cheers,
>> |  >> Joachim
>> |  >>
>> |  >> --
>> |  >> Joachim Breitner
>> |  >> mail at joachim-breitner.de
>> |  >>
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>> |  achim-
>> |  breitner.de
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>
>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>
>> %7Cfa6e3a6bcdf
>> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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/20200930/f8edfeb3/attachment-0001.html>

From trupill at gmail.com  Wed Sep 30 20:12:07 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 30 Sep 2020 22:12:07 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
Message-ID: <CAHnFXOsFBAqS0FxgcZegv6Hc+P-1U=zH629px3xfPAQQDEn3Xg@mail.gmail.com>

Of course, I could also write some proposal, and then we can use the usual
PR mechanism to discuss it.

Alejandro

El mié., 30 sept. 2020 a las 22:06, Alejandro Serrano Mena (<
trupill at gmail.com>) escribió:

> Dear all,
> I've started working on a proposal for GHC2020. You can see the current
> status here:
> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
>
> I noticed the list by Richard was not exhaustive. Those extensions are
> headed by "In discussion". Preferably we should make up our minds before
> presenting the proposal. I would say there are three big groups of
> proposals. Any feedback is welcome on that part.
>
> Regards,
> Alejandrp
>
> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
> iavor.diatchki at gmail.com>) escribió:
>
>> Thanks Alejandro.  My preference would be that you share whatever you
>> come up with the list so we can discuss it, before making a proposal that
>> would represent the committee.
>> -Iavor
>>
>> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>>> OK by me.   Thank you
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>> Serrano Mena
>>> *Sent:* 29 September 2020 15:51
>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> I am still happy to drive this! I was not sure about whether we agreed
>>> as a Committee on pushing this.
>>>
>>>
>>>
>>> To make this more actionable, my goal is, *during next Sunday*, to
>>> create a new proposal with the *criteria* (based on Richard + Simon's
>>> list), and a preliminary assessment of which of the *current extensions*
>>> satisfy these criteria, and for those we might be willing to grant
>>> *exceptions*.
>>>
>>>
>>>
>>> Please raise your voice if you think we should proceed otherwise (or if
>>> you think we should not proceed at all!).
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev>)
>>> escribió:
>>>
>>> What's the status of this push? I was delighted to see that Alejandro
>>> volunteered to be a motive force on this idea, and have thus refrained (as
>>> I am pushing on other ideas, too). But I also don't want this to die. :)
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Richard
>>>
>>>
>>>
>>> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> I agree with using the criteria that Richard posted + the addition by
>>> Simon. Just in case somebody hadn't looked at the wiki, the criteria would
>>> be:
>>>
>>>    1. The extension is (mostly) conservative: All programs that were
>>>    accepted without the extension remain accepted, and with the same meaning.
>>>    2. New failure modes that become possible with the extension are
>>>    rare and/or easy to diagnose. (These failure modes include new error
>>>    messages, wrong inferred types, and runtime errors, for example.)
>>>    3. The extensions complement the design of standard Haskell. (This
>>>    one seems the most subjective.)
>>>    4. The extension has been -- and can reasonably be predicted to
>>>    remain -- stable.
>>>    5. The extension is not to gate-keep an advanced or
>>>    potentially-unsafe feature.
>>>    6. The extension is widely-used.
>>>
>>> For example, should we add to (6) "in current developments"? What about
>>> things like "EmptyDataDecls", which are just straightforward
>>> generalizations of what Haskell 2010 already allows, although in practice
>>> the only data type you would ever need to be empty is "Void"?
>>>
>>>
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
>>> escribió:
>>>
>>> I think there should be some requirement that an extension be
>>> widely-used (for some suitable definition of that), before we ratify it in
>>> GHC2020. Some of the extensions that made it past the first round of
>>> filtering are not widely-used, and would be therefore probably be
>>> controversial additions to a language standard - e.g. ViewPatterns,
>>> ParallelListComp, RecursiveDo to name a few that I noticed straight off. I
>>> think it's a good idea to be conservative here.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Simon
>>>
>>>
>>>
>>> On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> There seems to be some question about who should drive this debate. But
>>> there is something we all seem to agree on: it is our role, as the steering
>>> committee, to announce the criteria by which we intend to judge the
>>> reasonableness of each potential candidate extension.
>>>
>>>
>>>
>>> So, let me suggest that we start discussing that, and move back to how
>>> this discussion ought to be driven when we are a bit clearer on the
>>> criteria.
>>>
>>>
>>>
>>> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
>>> that they are worthy of discussion. So let me ask the question: do we agree
>>> with all these criteria? do we want to add more?
>>>
>>>
>>>
>>> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>
>>>
>>>
>>>
>>> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <
>>> trupill at gmail.com> wrote:
>>>
>>> I would rather make the process Committee-driven, because otherwise it
>>> may derail into too many micro-discussions. I think it's better to start a
>>> conversation saying "this is our proposal, here are our criteria, here are
>>> the exceptions we want to make", and then discuss from there.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>>
>>>
>>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>>> escribió:
>>>
>>> I think we may want to have the Committee initiate and drive the
>>> process. I think a GHC20XX proposal will turn into a bunch of micro
>>> proposals and discussions about individual (groups of) extensions, and it
>>> will be hard to track all of the threads of discussion in a single GitHub
>>> thread. We’ve dealt with long and contentious discussions before, but they
>>> were much more focused than GHC20XX will be, by design.
>>>
>>>
>>>
>>> I suggested earlier that an alternative strategy could be to open a new
>>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>>> process, with each proposed group of extensions getting its own PR and
>>> discussion. There are a few open questions here though. When/how do we
>>> decide that it’s time for a new standard? How do we decide when the full
>>> proposal is ready for review? Do we need to review and sign off on each
>>> group of extensions separately or only the final product?
>>>
>>>
>>>
>>> This process would be a lot more work for us, so I’m happy to try the
>>> usual process first, and I’ll be happy to be proved wrong. But we should be
>>> prepared to step in and add some more structure if needed.
>>>
>>>
>>>
>>> Regardless, the first step should be to update our docs to express
>>> interest in GHC20XX proposals, establish criteria for including language
>>> extensions, and outline a process for submitting them.
>>>
>>>
>>>
>>> Eric
>>>
>>> Sent from my iPhone
>>>
>>>
>>>
>>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>
>>> 
>>>
>>> Personally I don’t think we should make the Steering Committee
>>> responsible for initiating or driving this.  We should
>>>
>>> ·         establish the criteria (including some idea of how frequently
>>> we’d be open to creating a new GHCxx version),
>>>
>>> ·         express open-ness to a proposal, and then
>>>
>>> ·         review proposals when/if they materialise.
>>>
>>>
>>>
>>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>>> that’s different from making the committee *responsible*.
>>>
>>>
>>>
>>> What do others think?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 08 September 2020 09:13
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>>> ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> Dear all,
>>>
>>> I would really like to move this forward, and I would be happy to put
>>> some work on it.
>>>
>>>
>>>
>>> What do you think of the following plan?
>>>
>>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>>> think the criteria in the wiki are quite nice. Explain that one of the
>>> goals is to encompass as many stable extensions as possible.
>>>
>>> - Reformat the list to make 3 tables: one for extensions which satisfy
>>> all 5 criteria, one for extensions we want to include even if they don't,
>>> and one for those which should be rejected in the light of those criteria.
>>>
>>>
>>>
>>> If the process works well, we could think about instaurating a
>>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>>
>>> Just back from holiday. Some thoughts
>>>
>>> * I don’t think this mailing list is the best place for the
>>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>>   a committee member, possibly not) should write a proposal,
>>>   and we should put it through the process.
>>>
>>> * We should advertise the criteria, as Richard has done on the
>>>   wiki page.
>>>
>>> * Any such proposal should be informed by data. Notably, extension usage
>>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>>
>>> * A proposer might also want to run a public poll, as an additional
>>>   source of data
>>>
>>> * When it comes to the committee, we can (I guess) vote on individual
>>>   extensions, rather than just accept/reject the whole thing.
>>>
>>> I am intrigued by the idea of using Kialo to coordinate discussion.
>>> Maybe it'd work better than GitHub?  Are there other alternatives?
>>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>>
>>> Simon
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-steering-committee <ghc-steering-committee-
>>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>>> |  Sent: 02 September 2020 14:57
>>> |  To: Eric Seidel <eric at seidel.io>
>>> |  Cc: ghc-steering-committee at haskell.org
>>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>>> |
>>> |  It seems clear that my wiki idea isn't winning the day -- I never
>>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>>> |  approach is that it seems hard to get good community involvement.
>>> |
>>> |  Richard
>>> |
>>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>>> |  >
>>> |  > Opening a regular discussion about whether and how we want to work
>>> on
>>> |  GHC 2020 sounds fine, that will also give the community a place to
>>> |  weigh in. I do think the eventual contents should be informed by the
>>> |  community though, it shouldn’t just be us working alone.
>>> |  >
>>> |  > Sent from my iPhone
>>> |  >
>>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>>
>>> wrote:
>>> |  >>
>>> |  >> Hi,
>>> |  >>
>>> |  >> sounds plausible. It would also allow us to use tags to easily
>>> |  indicate
>>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…),
>>> and
>>> |  >> then filter by issue to get the current list…
>>> |  >>
>>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>>> |  on
>>> |  >>
>>> |  >> * do we even want that?
>>> |  >> * what are the abstract criteria (or guidelines)?
>>> |  >> * what is the process?
>>> |  >>
>>> |  >> I believe that discussion could be done like any other proposal.
>>> |  >>
>>> |  >>
>>> |  >> As for the process; when I brought up the idea, I was worried about
>>> |  us
>>> |  >> spending huge resources discussion individual extensions to death,
>>> |  and
>>> |  >> proposed, in the interest of efficiency and getting things done:
>>> |  >>
>>> |  >>> The process could be: Every member can nominate any number of
>>> |  >>> extensions, to include, maybe a small rationale and then we do one
>>> |  >>> round of independent approval voting, requiring a supermajority to
>>> |  >>> really only pick uncontested extensions.
>>> |  >>
>>> |  >> So instead of long debates, we start with GHC2020 being just those
>>> |  >> extensions that a supermajority on the committee considers to be
>>> ok.
>>> |  >>
>>> |  >> This is much more lightweight process that we could get done in a
>>> |  week
>>> |  >> or two (maybe using a doodle-like voting page). Maybe we would
>>> leave
>>> |  >> out one or two extension that initially people are reserved about,
>>> |  but
>>> |  >> could be swayed after lengthy discussions. But is that worth the
>>> |  >> lengthy discussion?
>>> |  >>
>>> |  >> cheers,
>>> |  >> Joachim
>>> |  >>
>>> |  >> --
>>> |  >> Joachim Breitner
>>> |  >> mail at joachim-breitner.de
>>> |  >>
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>>> |  achim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>
>>> %2F&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>
>>> %7Cfa6e3a6bcdf
>>> |
>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>> |
>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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/20200930/38b515c2/attachment-0001.html>