From mail at joachim-breitner.de  Tue Sep 14 07:38:46 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 09:38:46 +0200
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
Message-ID: <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>

Hi,


on the multiway-lambda story, we have voted to add \cases alongside
\case. But one open question is still: Do we 
 (1) add -XLambdaCases (which would imply -XLambdaCase) or
 (2) simply expand the meaning of -XLambdaCase.

On the Github thread at 
https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
we see that I lean towards (1), but SPJ leands towards (2).

It doesn’t matter that much, but we need to make a decision. Can I
please get some opinions from the rest of the committee on this point?

Cheers,
Joachim


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



From mail at joachim-breitner.de  Tue Sep 14 07:45:10 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 09:45:10 +0200
Subject: [ghc-steering-committee] Please review #400: Constrained
 COMPLETE sets, Shepherd: Vladislav
In-Reply-To: <B0AE5B26-BEB5-4F11-AA89-257C96838FAC@gmail.com>
References: <e2d6e356378b1d920f4277c633aaf65fdbe9d287.camel@joachim-breitner.de>
 <14f7d2ffdc4a0f25e5d235e7b98863879f2677f9.camel@joachim-breitner.de>
 <B0AE5B26-BEB5-4F11-AA89-257C96838FAC@gmail.com>
Message-ID: <7af80051054a5af609d89995aa1927c55ad2bc72.camel@joachim-breitner.de>

Hi Vlad,

this was resubmitted. Can you make a recommendation or send it back?

Cheers,
Joachim

Am Dienstag, dem 15.06.2021 um 10:01 +0300 schrieb Vladislav Zavialov
(int-index):
> I have read the proposal and sent it back for revision, as I found that the change is underspecified (the interaction with GADTs is unclear).
> 
> - Vlad
> 
> > On 11 Jun 2021, at 18:15, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Dear Committee,
> > 
> > it looks like Cale will not be able to handle this one, so I’d like to
> > reassign to Vladislav.
> > 
> > Vladislav, maybe comment on the Github thread that you are taking over,
> > so that the author knows something is happening now, and ideally don’t
> > let him wait too long here.
> > 
> > Cheers,
> > Joachim
> > 
> > Am Montag, den 22.02.2021, 12:30 +0100 schrieb Joachim Breitner:
> > > Dear Committee,
> > > 
> > > this is your secretary speaking:
> > > 
> > > Constrained COMPLETE sets
> > > has been proposed by Sebastian Graph
> > > https://github.com/ghc-proposals/ghc-proposals/pull/400
> > > https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-constrained-complete-sets.rst
> > > 
> > > 
> > > This proposal tries to solve the same issue as Cale’s #399, and
> > > essentially has slightly different syntax. I therefore suggest that
> > > Cale is the shepherd, and hashes out with Sebastian the details of
> > > syntax so that they can both get behind it, and then makes a
> > > recommendation.
> > > 
> > > Please guide us to a conclusion as outlined in 
> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > 
> > > Thanks,
> > > Joachim
> > -- 
> > Joachim Breitner
> >  mail at joachim-breitner.de
> >  http://www.joachim-breitner.de/
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From mail at joachim-breitner.de  Tue Sep 14 07:47:19 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 09:47:19 +0200
Subject: [ghc-steering-committee] #390: Fine-grained pragmas,
 recommendation: accept
In-Reply-To: <CAHnFXOspmpv4FTOGPv3gwnZqNRP_o1MdtRjb0TMhMaA6z0u2pg@mail.gmail.com>
References: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>
 <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com>
 <CALpVSmMKSn3o+0_rzvxUckeEykY_Jk5tGRLBrFf12t1H_bZ0QA@mail.gmail.com>
 <CALpVSmM-hu0rD0euXBy99+kRb2ioR4rc_Haa5=3PX_7sV=VVnQ@mail.gmail.com>
 <010f017a9afd2eea-bbac2727-573e-4423-a5a9-fc69d9b16703-000000@us-east-2.amazonses.com>
 <CAHnFXOspmpv4FTOGPv3gwnZqNRP_o1MdtRjb0TMhMaA6z0u2pg@mail.gmail.com>
Message-ID: <ffeb5d03d01e3dc562dca40a9470dc0992c80837.camel@joachim-breitner.de>

Hi Vitaly,

what is the status of this? Richard said he supports acceptance, but I
am not sure if there are still open questions?

Cheers,
Joachim

Am Freitag, dem 23.07.2021 um 07:44 +0000 schrieb Alejandro Serrano
Mena:
>  Dear all,
> I’ve just updated the proposal following a great suggestion by Vlad.
> 
> Unfortunately, I don’t know enough about GHC’s parsing machinery to
> answer the question posed by Richard. I’ll repeat it in case somebody
> in the Committee can shed some light on it:
> 
> > The proposal use ; to separate the modifiers from the declarations.
> > Combined with the layout rule this allows us to write in two forms:
> > 
> > 
> > 
> >  > %NoTerminationCheck ; instance C Int where ...
> > 
> > 
> > > %NoTerminationCheck
> > > instance C Int where …
> > 
> > Would it be possible to allow the modifier to simply precede the
> > `instance` without turning the parser into a mess?
> > 
> 
> Regards,
> Alejandro
> 
> El 12 jul 2021 15:52:01, Richard Eisenberg <lists at richarde.dev>
> escribió:
>  
> > I'm happy with this updated proposal, though I've made a small
> > suggestion about making the ;s optional.
> > 
> > Regardless of whether this suggestion is taken, I support
> > acceptance.
> > 
> > Thanks,
> > Richard
> > 
> > > On Jul 4, 2021, at 5:12 AM, Vitaly Bragilevsky
> > > <bravit111 at gmail.com> wrote:
> > > 
> > > Dear Committee, 
> > > 
> > > I'm happy to repeat my recommendation to accept Alejandro's
> > > proposal which is now back from revision:
> > > Fine-grained pragmas for classes, families, and instances
> > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > 
> > > All the issues that arose in the previous discussion are now
> > > resolved. Does anyone have something to add? 
> > > 
> > > Vitaly
> > > 
> > > 
> > > 
> > > сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky
> > > <bravit111 at gmail.com>:
> > > > чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index)
> > > > <vlad.z.4096 at gmail.com>:
> > > > > I like the proposal and I would be happy to vote for its
> > > > > acceptance. However, it requires a little bit of polishing up
> > > > > with regards to its use of modifiers. In particular, it seems
> > > > > to treat modifiers as built-in units, whereas the core idea
> > > > > behind modifiers is that they are based on actual promoted
> > > > > types (with the exception of %1).
> > > > > 
> > > > > Hence it seems appropriate to send it back for revision until
> > > > > this point is addressed.
> > > > > 
> > > > 
> > > > 
> > > > Yes, I agree. There is also another issue. I think we need
> > > > either a deprecation story for UndecidableInstances, or a
> > > > statement that it should survive with some motivation behind
> > > > that. 
> > > > 
> > > > So, I'm sending this proposal back to Alejandro for review and
> > > > set the "needs revision" label on GitHub.
> > > > 
> > > > Vitaly 
> > > > > 
> > > > > - Vlad
> > > > > 
> > > > > > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky
> > > > > <bravit111 at gmail.com> wrote:
> > > > > > 
> > > > > > Dear Committee,
> > > > > > 
> > > > > > Our own Alejandro has been proposed
> > > > > > Fine-grained pragmas for classes, families, and instances
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > > > > 
> > > > > https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > > > > 
> > > > > > His idea is to bring the flexibility of
> > > > > overlaps/overlapping/overlappable pragmas to termination
> > > > > checking, type inference, and constraint solving. Alejandro
> > > > > proposes to introduce the following %-modifiers (as in
> > > > > already
> > > > > accepted #370,
> > > > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst
> > > > > ):
> > > > > > %NoTerminationCheck
> > > > > > %LiberalCoverage
> > > > > > %LiberalInjectivity
> > > > > > %Overlapping
> > > > > > %Overlappable
> > > > > > %Overlaps
> > > > > > to liberate conditions for classes and instances, type
> > > > > families, forall-types, etc. The first three modifiers can be
> > > > > used instead of the scary-sounding UndecidableInstances
> > > > > extension. The last three modifiers are supposed to be used
> > > > > instead of the  overlap*-pragmas for instances we already
> > > > > have.
> > > > > Note that this proposal doesn't suggest deprecating those
> > > > > extensions and pragmas.
> > > > > > 
> > > > > > I think that this proposal goes in the right direction and
> > > > > recommend accepting it.
> > > > > > 
> > > > > > As far as I understand, all the committee members,
> > > > > > including
> > > > > those with terms about to expire, have the right to either
> > > > > support this proposal or to raise a voice against it either
> > > > > here or at
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390.
> > > > > > 
> > > > > > Regards,
> > > > > > Vitaly
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > 
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> >  _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From mail at joachim-breitner.de  Tue Sep 14 07:51:41 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 09:51:41 +0200
Subject: [ghc-steering-committee] Proposal #412: Explicit Splice Imports;
 rec: accept
In-Reply-To: <010f017ac0728427-77a68b3e-a9c5-4d68-9f62-0b89d9f6756d-000000@us-east-2.amazonses.com>
References: <DE8C2209-960F-4BBC-A199-E6DBC7D7DE7A@gmail.com>
 <CAHnFXOvP5YaOAi5=0m4-2igmbmHvrNXsxduvU=-nypn=rharsw@mail.gmail.com>
 <CAH6fHQnTPae2nWE0-=z2WFqcxNaJLr1xnnPT0cSDpKk434E-pw@mail.gmail.com>
 <010f017ac0728427-77a68b3e-a9c5-4d68-9f62-0b89d9f6756d-000000@us-east-2.amazonses.com>
Message-ID: <bd3ea09686010e0b2ae7b9eebce29273d9d32ee1.camel@joachim-breitner.de>

Hi,

It looks like we have consensus, but I see there is was some more
discussion after that on the Github trail. Back to revision? Or can we
accept as it is?

Cheers,
Joachim

Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg:
> I support acceptance of the proposal.
> 
> RIchard
> 
> > On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud
> > <arnaud.spiwack at tweag.io> wrote:
> > 
> > I agree with the sentiment so far: this is a well constructed
> > proposal which makes a good case for the fine details of the
> > proposed specification. The goal is also quite desirable (it has
> > been brought up by other before, such as
> > http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/
> > or https://github.com/ghc-proposals/ghc-proposals/pull/243 ).
> > 
> > On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena
> > <trupill at gmail.com> wrote:
> > >  Dear all,
> > > I like the proposal, and I think my life will automatically
> > > improve with this.
> > > 
> > > Alejandro
> > > 
> > > El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index)
> > > <vlad.z.4096 at gmail.com> escribió:
> > >  
> > > >  Dear Committee,
> > > > 
> > > > Proposal #412 "Explicit Splice Imports” by Matthew Pickering
> > > > has been submitted for our consideration.
> > > > 
> > > > Read it here:
> > > > https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0000-splice-imports.rst
> > > > Discussion here:
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/412
> > > > 
> > > > The goals of this proposal are to (1) improve parallel
> > > > compilation, (2) speed up -fno-code and IDEs that rely on it,
> > > > (3) reduce binary sizes or at least reduce linking overhead,
> > > > (4) create phase separation useful for cross-compilation.
> > > > 
> > > > All of the above are achieved by introducing a new form of
> > > > import called a splice-import. Compare:
> > > > 
> > > >   import M
> > > >   import splice H
> > > > 
> > > > Under this proposal, names imported from M can *not* be used in
> > > > top-level Template Haskell splices, whereas names imported from
> > > > H can be used *only* in Template Haskell splices.
> > > > 
> > > > At this point I will note that I do not particularly like the
> > > > proposed syntax, which looks as if we’re importing a splice
> > > > rather than importing names for use in splices. In the
> > > > “Alternatives” section, you will find several other options
> > > > such as “import {-# SPLICE #-} M”, “import for splice H”,
> > > > “$(import H)”, and so on. That said, let us not get bogged down
> > > > in the discussion of syntax before we agree on the semantics.
> > > > If we choose to accept the proposal, I will organize a vote on
> > > > the syntax.
> > > > 
> > > > Regarding the semantics, I believe the general idea behind the
> > > > proposal is good, and I recommend acceptance. It provides a way
> > > > for the programmer to specify the intended usage of an import
> > > > (whether it is for normal programming or metaprogramming), and
> > > > GHC can use this information to build the program more
> > > > effectively (more parallelism, less linking). In ways that I do
> > > > not entirely understand, it is allegedly good for future work
> > > > on cross-compilation.
> > > > 
> > > > Let me know what you think.
> > > > 
> > > > - Vlad
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From vlad.z.4096 at gmail.com  Tue Sep 14 07:55:04 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Tue, 14 Sep 2021 10:55:04 +0300
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
Message-ID: <306AAB7C-5C6E-4529-936C-F663BB685DCF@gmail.com>

We should give our users the option to keep using LambdaCase without enabling LambdaCases. I, for one, do not like the flavor we ended up choosing, so I’d keep using LambdaCase alone in my programs. I imagine other users might want to do so as well.

- Vlad

> On 14 Sep 2021, at 10:38, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> 
> on the multiway-lambda story, we have voted to add \cases alongside
> \case. But one open question is still: Do we 
> (1) add -XLambdaCases (which would imply -XLambdaCase) or
> (2) simply expand the meaning of -XLambdaCase.
> 
> On the Github thread at 
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> we see that I lean towards (1), but SPJ leands towards (2).
> 
> It doesn’t matter that much, but we need to make a decision. Can I
> please get some opinions from the rest of the committee on this point?
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Tue Sep 14 08:01:06 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 10:01:06 +0200
Subject: [ghc-steering-committee]  GHC Steering Committee Status
Message-ID: <537611fc9fa9ef8154e88108d3cf0bfb00e36113.camel@joachim-breitner.de>

Dear Committee,

I hope you all had a lovely summer, an interesting ICFP and Haskell
Love and other conferences, and are slowly moving back into action.

What has happened since the last status (on July 1st)?

 * Simon suggested a better way to keep tabs on what’s going on. I’ll
   try to keep https://github.com/ghc-proposals/ghc-proposals/wiki/Status 
   as up to date as the latest status email.

   I ran out of time today, so I did not yet try to make the format
   tabular and prettier. Sorry, next time!

   But I added a time stamp to each that roughly corresponds to the
   latest state change.

 * Cale has stepped down. Thanks for your contributions!

 * we were asked to review these proposals:
  
   #319: NoFallibleDo proposal (resubmission)
   #425: Invisible binders in type declarations, Shepherd: Richard

 * we have a recommendation from the shepherd about:

   #390: Fine-grained pragmas (accept)
   #319: NoFallibleDo proposal (reject)

 * we have sent the following proposals back to revision

   #390: Fine-grained pragmas
   #315: NoIncomplete (author wants to revisit)

 * we decided about the following proposals

   none this round?


We currently have to act on the following 9 proposals, same as last
round.

## Waiting for committee decision

#281: Visible 'forall' in types of terms, Shepherd: Richard
      2021-07-19: After still some more discussion, Richard again recommends
      to accept this, answering Simon M’s questions.
      Simon, are you fine with that?

#283: Local modules, Shepherd: Arnaud
      2021-05-20: Arnaud recommends to accepts, and wants more opinions.
      Opinions still sparse. Please give it! 

#302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ
      2021-07-29: Vote done, one open question about pragma design.

#319: NoFallibleDo, Shepherd: Alejandro
      2021-07-23: Rejection recommended
      Committee comments please?

#392: Clarify modifiers design principle (Shepherd: Alejandro)
      2021-07-23: Alejandro asked for more eyes.
      Discussion about grammar and compatibility with #390 open

#409: Exportable named defaults, Shepherd: Eric
      2021-09-10: SPJ wants to have a last look, reminder is set

#412: splice imports, Shepherd: Vladislav
      2021-06-24: Acceptance recommended
      Positive feedback so far, but more discussion
      Shall we accept it, Vladislav?


## Waiting for Shepherd action

#400: Constrained COMPLETE sets, Shepherd: Vladislav
      2021-06-22: Waiting for recommendation.
      Vladislav, time to get active!

#425: Invisible binders in type declarations, Shepherd: Richard
      2021-08-13: Waiting for recommendation.




Cheers,
Joachim


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



From mail at joachim-breitner.de  Tue Sep 14 08:02:56 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 14 Sep 2021 10:02:56 +0200
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <306AAB7C-5C6E-4529-936C-F663BB685DCF@gmail.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <306AAB7C-5C6E-4529-936C-F663BB685DCF@gmail.com>
Message-ID: <651f7ab898eacc4ce080e7911cd31df80d6add8f.camel@joachim-breitner.de>

Hi,

I don’t think language pragmas are about choice in that sense. Either
we don’t want the feature (then we’d reject it), or we want it to
eventually become a viable default (at least for add-on extensions like
this). So at some day I expect GHC20xx to allow both \case and \cases.
Nobody forces to to _use_ \cases in your code, however!

The question is more about: do we want extensions to evolve over time,
or be more immutable (I don’t think we want to commit to full
immutability).

Cheers,
Joachim

Am Dienstag, dem 14.09.2021 um 10:55 +0300 schrieb Vladislav Zavialov
(int-index):
> We should give our users the option to keep using LambdaCase without enabling LambdaCases. I, for one, do not like the flavor we ended up choosing, so I’d keep using LambdaCase alone in my programs. I imagine other users might want to do so as well.
> 
> - Vlad
> 
> > On 14 Sep 2021, at 10:38, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > 
> > on the multiway-lambda story, we have voted to add \cases alongside
> > \case. But one open question is still: Do we 
> > (1) add -XLambdaCases (which would imply -XLambdaCase) or
> > (2) simply expand the meaning of -XLambdaCase.
> > 
> > On the Github thread at 
> > https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> > we see that I lean towards (1), but SPJ leands towards (2).
> > 
> > It doesn’t matter that much, but we need to make a decision. Can I
> > please get some opinions from the rest of the committee on this point?
> > 
> > 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

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



From vlad.z.4096 at gmail.com  Tue Sep 14 09:56:14 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Tue, 14 Sep 2021 12:56:14 +0300
Subject: [ghc-steering-committee] Proposal #412: Explicit Splice Imports;
 rec: accept
In-Reply-To: <bd3ea09686010e0b2ae7b9eebce29273d9d32ee1.camel@joachim-breitner.de>
References: <DE8C2209-960F-4BBC-A199-E6DBC7D7DE7A@gmail.com>
 <CAHnFXOvP5YaOAi5=0m4-2igmbmHvrNXsxduvU=-nypn=rharsw@mail.gmail.com>
 <CAH6fHQnTPae2nWE0-=z2WFqcxNaJLr1xnnPT0cSDpKk434E-pw@mail.gmail.com>
 <010f017ac0728427-77a68b3e-a9c5-4d68-9f62-0b89d9f6756d-000000@us-east-2.amazonses.com>
 <bd3ea09686010e0b2ae7b9eebce29273d9d32ee1.camel@joachim-breitner.de>
Message-ID: <2AF43074-CB9D-41BA-A351-7F0A09B6F980@gmail.com>

I sent it back for revision until the author decides whether we want quote imports or not.

This is still on the trajectory to acceptance, though.

- Vlad

> On 14 Sep 2021, at 10:51, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> It looks like we have consensus, but I see there is was some more
> discussion after that on the Github trail. Back to revision? Or can we
> accept as it is?
> 
> Cheers,
> Joachim
> 
> Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg:
>> I support acceptance of the proposal.
>> 
>> RIchard
>> 
>>> On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud
>>> <arnaud.spiwack at tweag.io> wrote:
>>> 
>>> I agree with the sentiment so far: this is a well constructed
>>> proposal which makes a good case for the fine details of the
>>> proposed specification. The goal is also quite desirable (it has
>>> been brought up by other before, such as
>>> http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/
>>> or https://github.com/ghc-proposals/ghc-proposals/pull/243 ).
>>> 
>>> On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena
>>> <trupill at gmail.com> wrote:
>>>>  Dear all,
>>>> I like the proposal, and I think my life will automatically
>>>> improve with this.
>>>> 
>>>> Alejandro
>>>> 
>>>> El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index)
>>>> <vlad.z.4096 at gmail.com> escribió:
>>>>  
>>>>>  Dear Committee,
>>>>> 
>>>>> Proposal #412 "Explicit Splice Imports” by Matthew Pickering
>>>>> has been submitted for our consideration.
>>>>> 
>>>>> Read it here:
>>>>> https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0000-splice-imports.rst
>>>>> Discussion here:
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/412
>>>>> 
>>>>> The goals of this proposal are to (1) improve parallel
>>>>> compilation, (2) speed up -fno-code and IDEs that rely on it,
>>>>> (3) reduce binary sizes or at least reduce linking overhead,
>>>>> (4) create phase separation useful for cross-compilation.
>>>>> 
>>>>> All of the above are achieved by introducing a new form of
>>>>> import called a splice-import. Compare:
>>>>> 
>>>>>   import M
>>>>>   import splice H
>>>>> 
>>>>> Under this proposal, names imported from M can *not* be used in
>>>>> top-level Template Haskell splices, whereas names imported from
>>>>> H can be used *only* in Template Haskell splices.
>>>>> 
>>>>> At this point I will note that I do not particularly like the
>>>>> proposed syntax, which looks as if we’re importing a splice
>>>>> rather than importing names for use in splices. In the
>>>>> “Alternatives” section, you will find several other options
>>>>> such as “import {-# SPLICE #-} M”, “import for splice H”,
>>>>> “$(import H)”, and so on. That said, let us not get bogged down
>>>>> in the discussion of syntax before we agree on the semantics.
>>>>> If we choose to accept the proposal, I will organize a vote on
>>>>> the syntax.
>>>>> 
>>>>> Regarding the semantics, I believe the general idea behind the
>>>>> proposal is good, and I recommend acceptance. It provides a way
>>>>> for the programmer to specify the intended usage of an import
>>>>> (whether it is for normal programming or metaprogramming), and
>>>>> GHC can use this information to build the program more
>>>>> effectively (more parallelism, less linking). In ways that I do
>>>>> not entirely understand, it is allegedly good for future work
>>>>> on cross-compilation.
>>>>> 
>>>>> Let me know what you think.
>>>>> 
>>>>> - Vlad
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> 
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simonpj at microsoft.com  Tue Sep 14 10:49:28 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 14 Sep 2021 10:49:28 +0000
Subject: [ghc-steering-committee] Proposal #412: Explicit Splice Imports;
 rec: accept
In-Reply-To: <2AF43074-CB9D-41BA-A351-7F0A09B6F980@gmail.com>
References: <DE8C2209-960F-4BBC-A199-E6DBC7D7DE7A@gmail.com>
 <CAHnFXOvP5YaOAi5=0m4-2igmbmHvrNXsxduvU=-nypn=rharsw@mail.gmail.com>
 <CAH6fHQnTPae2nWE0-=z2WFqcxNaJLr1xnnPT0cSDpKk434E-pw@mail.gmail.com>
 <010f017ac0728427-77a68b3e-a9c5-4d68-9f62-0b89d9f6756d-000000@us-east-2.amazonses.com>
 <bd3ea09686010e0b2ae7b9eebce29273d9d32ee1.camel@joachim-breitner.de>
 <2AF43074-CB9D-41BA-A351-7F0A09B6F980@gmail.com>
Message-ID: <VI1PR83MB02697F132C86B58F912CAAE7ADDA9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

|  This is still on the trajectory to acceptance, though.

In the light of Matthew's comment "it's not clear to me now how splice imports should work" (and the issues he describes in that post) the proposal has become less attractive to me. I'm no longer sure it's on a "trajectory to acceptance".  Let's just look at the revision with fresh eyes.

Simon
 

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com instead.  (For now, it just forwards to simonpj at microsoft.com.)

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Vladislav Zavialov (int-index)
|  Sent: 14 September 2021 10:56
|  To: Joachim Breitner <mail at joachim-breitner.de>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal #412: Explicit Splice
|  Imports; rec: accept
|  
|  I sent it back for revision until the author decides whether we want
|  quote imports or not.
|  
|  This is still on the trajectory to acceptance, though.
|  
|  - Vlad
|  
|  > On 14 Sep 2021, at 10:51, Joachim Breitner <mail at joachim-
|  breitner.de> wrote:
|  >
|  > Hi,
|  >
|  > It looks like we have consensus, but I see there is was some more
|  > discussion after that on the Github trail. Back to revision? Or can
|  we
|  > accept as it is?
|  >
|  > Cheers,
|  > Joachim
|  >
|  > Am Montag, dem 19.07.2021 um 20:26 +0000 schrieb Richard Eisenberg:
|  >> I support acceptance of the proposal.
|  >>
|  >> RIchard
|  >>
|  >>> On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud
|  >>> <arnaud.spiwack at tweag.io> wrote:
|  >>>
|  >>> I agree with the sentiment so far: this is a well constructed
|  >>> proposal which makes a good case for the fine details of the
|  >>> proposed specification. The goal is also quite desirable (it has
|  >>> been brought up by other before, such as
|  >>>
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblo
|  >>> g.ezyang.com%2F2016%2F07%2Fwhat-template-haskell-gets-wrong-and-
|  rack
|  >>> et-gets-
|  right%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c
|  >>>
|  35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
|  >>>
|  0%7C637672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  >>>
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jMMrN
|  >>> rwrmy4u6Tb6sq73iDU7SfCGYm49BkPdgXa%2BYfU%3D&amp;reserved=0
|  >>> or
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F243&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27
|  792c35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pdti7z6
|  4DefvJfsFeC9MWvln962hfuruh9zZQs4%2FI%2Fg%3D&amp;reserved=0 ).
|  >>>
|  >>> On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena
|  >>> <trupill at gmail.com> wrote:
|  >>>>  Dear all,
|  >>>> I like the proposal, and I think my life will automatically
|  improve
|  >>>> with this.
|  >>>>
|  >>>> Alejandro
|  >>>>
|  >>>> El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index)
|  >>>> <vlad.z.4096 at gmail.com> escribió:
|  >>>>
|  >>>>>  Dear Committee,
|  >>>>>
|  >>>>> Proposal #412 "Explicit Splice Imports" by Matthew Pickering has
|  >>>>> been submitted for our consideration.
|  >>>>>
|  >>>>> Read it here:
|  >>>>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
|  >>>>> github.com%2Fmpickering%2Fghc-proposals%2Fblob%2Fsplice-
|  imports%2F
|  >>>>> proposals%2F0000-splice-
|  imports.rst&amp;data=04%7C01%7Csimonpj%40m
|  >>>>>
|  icrosoft.com%7C27792c35c4544a26508c08d97765e7cf%7C72f988bf86f141af
|  >>>>>
|  91ab2d7cd011db47%7C1%7C0%7C637672103914375977%7CUnknown%7CTWFpbGZs
|  >>>>>
|  b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
|  >>>>>
|  0%3D%7C1000&amp;sdata=Cl4DNgqIPcjr9hBRrNNiVS40v8Guwd47PZ0p9AdFkQQ%
|  >>>>> 3D&amp;reserved=0
|  >>>>> Discussion here:
|  >>>>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
|  >>>>> github.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F412&amp;data=0
|  >>>>>
|  4%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d97765e7c
|  >>>>>
|  f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672103914375977%
|  >>>>>
|  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
|  >>>>>
|  I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pEUWmUUICGVirnVpY13lHtAi
|  >>>>> xYqLW11guSwLvf30mk0%3D&amp;reserved=0
|  >>>>>
|  >>>>> The goals of this proposal are to (1) improve parallel
|  >>>>> compilation, (2) speed up -fno-code and IDEs that rely on it,
|  >>>>> (3) reduce binary sizes or at least reduce linking overhead,
|  >>>>> (4) create phase separation useful for cross-compilation.
|  >>>>>
|  >>>>> All of the above are achieved by introducing a new form of
|  import
|  >>>>> called a splice-import. Compare:
|  >>>>>
|  >>>>>   import M
|  >>>>>   import splice H
|  >>>>>
|  >>>>> Under this proposal, names imported from M can *not* be used in
|  >>>>> top-level Template Haskell splices, whereas names imported from
|  H
|  >>>>> can be used *only* in Template Haskell splices.
|  >>>>>
|  >>>>> At this point I will note that I do not particularly like the
|  >>>>> proposed syntax, which looks as if we're importing a splice
|  rather
|  >>>>> than importing names for use in splices. In the "Alternatives"
|  >>>>> section, you will find several other options such as "import {-#
|  >>>>> SPLICE #-} M", "import for splice H", "$(import H)", and so on.
|  >>>>> That said, let us not get bogged down in the discussion of
|  syntax
|  >>>>> before we agree on the semantics.
|  >>>>> If we choose to accept the proposal, I will organize a vote on
|  the
|  >>>>> syntax.
|  >>>>>
|  >>>>> Regarding the semantics, I believe the general idea behind the
|  >>>>> proposal is good, and I recommend acceptance. It provides a way
|  >>>>> for the programmer to specify the intended usage of an import
|  >>>>> (whether it is for normal programming or metaprogramming), and
|  GHC
|  >>>>> can use this information to build the program more effectively
|  >>>>> (more parallelism, less linking). In ways that I do not entirely
|  >>>>> understand, it is allegedly good for future work on
|  >>>>> cross-compilation.
|  >>>>>
|  >>>>> Let me know what you think.
|  >>>>>
|  >>>>> - Vlad
|  >>>>> _______________________________________________
|  >>>>> ghc-steering-committee mailing list
|  >>>>> ghc-steering-committee at haskell.org
|  >>>>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
|  >>>>> mail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  com
|  >>>>>
|  mittee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a
|  >>>>>
|  26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  >>>>>
|  7672103914375977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  >>>>>
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BQsupcr
|  >>>>> 1P1EVbPn24sSKAKmsb7PtqBwsr5sXw9OvYRE%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%2Fm
|  >>>> ail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  commi
|  >>>>
|  ttee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a265
|  >>>>
|  08c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672
|  >>>>
|  103914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
|  >>>>
|  luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yNaMf3apYlBi9
|  >>>> gOrWjPKa%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&amp;reserved=0
|  >>> _______________________________________________
|  >>> ghc-steering-committee mailing list
|  >>> ghc-steering-committee at haskell.org
|  >>>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
|  >>> il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committ
|  >>>
|  ee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c
|  >>>
|  08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376721039
|  >>>
|  14385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
|  >>>
|  iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yNaMf3apYlBi9gOrWjP
|  >>> Ka%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&amp;reserved=0
|  >>
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org
|  >>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
|  >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee
|  >>
|  &amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d
|  >>
|  97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63767210391438
|  >>
|  5971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
|  >>
|  TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yNaMf3apYlBi9gOrWjPKa%2B%
|  >> 2FIsBtdQFZMrFeLLx61UWQ%3D&amp;reserved=0
|  >
|  > --
|  > Joachim Breitner
|  >  mail at joachim-breitner.de
|  >
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C277
|  >
|  92c35c4544a26508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
|  >
|  C0%7C637672103914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
|  >
|  JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wg9N5%2F
|  > zQwRWTCtFqswzUVIqqQBo%2Fts7wgKsPP4N1X1E%3D&amp;reserved=0
|  >
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&a
|  >
|  mp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a26508c08d977
|  >
|  65e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672103914385971
|  >
|  %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
|  >
|  k1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yNaMf3apYlBi9gOrWjPKa%2B%2FIsBt
|  > dQFZMrFeLLx61UWQ%3D&amp;reserved=0
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C27792c35c4544a2
|  6508c08d97765e7cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376721
|  03914385971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=yNaMf3apYlBi9gOrWjPK
|  a%2B%2FIsBtdQFZMrFeLLx61UWQ%3D&amp;reserved=0

From arnaud.spiwack at tweag.io  Tue Sep 14 15:42:58 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 14 Sep 2021 17:42:58 +0200
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <651f7ab898eacc4ce080e7911cd31df80d6add8f.camel@joachim-breitner.de>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <306AAB7C-5C6E-4529-936C-F663BB685DCF@gmail.com>
 <651f7ab898eacc4ce080e7911cd31df80d6add8f.camel@joachim-breitner.de>
Message-ID: <CAH6fHQkRueXGVEA1fQ36Mmt_9VjrnksUwxAoxpFaL1QWTDJWxw@mail.gmail.com>

I'm personally quite fine with mutating extensions.

In this particular case (ha!) I am in favour of expaning the meaning of the
current extension (I thought I'd opine in that sense on the thread already,
but I appear not to have done so, ah well).

On Tue, Sep 14, 2021 at 10:03 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> I don’t think language pragmas are about choice in that sense. Either
> we don’t want the feature (then we’d reject it), or we want it to
> eventually become a viable default (at least for add-on extensions like
> this). So at some day I expect GHC20xx to allow both \case and \cases.
> Nobody forces to to _use_ \cases in your code, however!
>
> The question is more about: do we want extensions to evolve over time,
> or be more immutable (I don’t think we want to commit to full
> immutability).
>
> Cheers,
> Joachim
>
> Am Dienstag, dem 14.09.2021 um 10:55 +0300 schrieb Vladislav Zavialov
> (int-index):
> > We should give our users the option to keep using LambdaCase without
> enabling LambdaCases. I, for one, do not like the flavor we ended up
> choosing, so I’d keep using LambdaCase alone in my programs. I imagine
> other users might want to do so as well.
> >
> > - Vlad
> >
> > > On 14 Sep 2021, at 10:38, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > >
> > > Hi,
> > >
> > >
> > > on the multiway-lambda story, we have voted to add \cases alongside
> > > \case. But one open question is still: Do we
> > > (1) add -XLambdaCases (which would imply -XLambdaCase) or
> > > (2) simply expand the meaning of -XLambdaCase.
> > >
> > > On the Github thread at
> > >
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> > > we see that I lean towards (1), but SPJ leands towards (2).
> > >
> > > It doesn’t matter that much, but we need to make a decision. Can I
> > > please get some opinions from the rest of the committee on this point?
> > >
> > > 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
>
> --
> 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/20210914/352906a5/attachment.html>

From lists at richarde.dev  Tue Sep 14 19:46:06 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 14 Sep 2021 19:46:06 +0000
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
Message-ID: <010f017be5d85a48-90f7f49b-76bb-4a49-ad09-d0704db87f6c-000000@us-east-2.amazonses.com>

I vote (2). We have so many extensions already -- I don't see the need for another.

Richard

> On Sep 14, 2021, at 3:38 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> 
> on the multiway-lambda story, we have voted to add \cases alongside
> \case. But one open question is still: Do we 
> (1) add -XLambdaCases (which would imply -XLambdaCase) or
> (2) simply expand the meaning of -XLambdaCase.
> 
> On the Github thread at 
> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> we see that I lean towards (1), but SPJ leands towards (2).
> 
> It doesn’t matter that much, but we need to make a decision. Can I
> please get some opinions from the rest of the committee on this point?
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Wed Sep 15 08:59:01 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 15 Sep 2021 10:59:01 +0200
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <010f017be5d85a48-90f7f49b-76bb-4a49-ad09-d0704db87f6c-000000@us-east-2.amazonses.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <010f017be5d85a48-90f7f49b-76bb-4a49-ad09-d0704db87f6c-000000@us-east-2.amazonses.com>
Message-ID: <581e1e4c88c663e8fa037625a39fd6c58fee40ea.camel@joachim-breitner.de>

Hi,

I sense a majority for just extending LambdaCase, and I see that that’s
simpler and less work and maybe good to avoid setting too high
expectations about immutability of extensions, so I’m happy to go with
it.

Simon, if that is good enough for you as “rough consensus” for you, we
merge it (the current proposal texts seems to go along with extending
LambdaCase).

Cheers,
Joachim

Am Dienstag, dem 14.09.2021 um 19:46 +0000 schrieb Richard Eisenberg:
> I vote (2). We have so many extensions already -- I don't see the need for another.
> 
> Richard
> 
> > On Sep 14, 2021, at 3:38 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > 
> > on the multiway-lambda story, we have voted to add \cases alongside
> > \case. But one open question is still: Do we 
> > (1) add -XLambdaCases (which would imply -XLambdaCase) or
> > (2) simply expand the meaning of -XLambdaCase.
> > 
> > On the Github thread at 
> > https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-895080031
> > we see that I lean towards (1), but SPJ leands towards (2).
> > 
> > It doesn’t matter that much, but we need to make a decision. Can I
> > please get some opinions from the rest of the committee on this point?
> > 
> > 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

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



From simonpj at microsoft.com  Wed Sep 15 12:00:26 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 15 Sep 2021 12:00:26 +0000
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Vitaly, Eric, Tom, Alejandro
As Joachim says, we need to make a decision on the LambdaCase flag issue.  It's a judgement call, so let's just vote.
Here is the voting sheet<https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs/edit?usp=sharing>.  I have filled in votes from Simon, myself, Joacim, Richard, Vlad.  But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two?  It should take you 5 minutes.
Thanks
Simon






PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com instead.  (For now, it just forwards to simonpj at microsoft.com.)



|  -----Original Message-----

|  From: ghc-steering-committee <ghc-steering-committee-

|  bounces at haskell.org> On Behalf Of Joachim Breitner

|  Sent: 14 September 2021 08:39

|  To: ghc-steering-committee at haskell.org

|  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda:

|  new extension or not?

|

|  Hi,

|

|

|  on the multiway-lambda story, we have voted to add \cases alongside

|  \case. But one open question is still: Do we

|   (1) add -XLambdaCases (which would imply -XLambdaCase) or

|   (2) simply expand the meaning of -XLambdaCase.

|

|  On the Github thread at

|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDY<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>

|  we see that I lean towards (1), but SPJ leands towards (2).

|

|  It doesn't matter that much, but we need to make a decision. Can I

|  please get some opinions from the rest of the committee on this point?

|

|  Cheers,

|  Joachim

|

|

|  --

|  Joachim Breitner

|    mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>

|

|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  oachim-<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec4<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>

|  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>

|  soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210915/8de9c47c/attachment-0001.html>

From eric at seidel.io  Wed Sep 15 13:01:35 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 15 Sep 2021 09:01:35 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23302=3A_Multiway_la?=
 =?utf-8?q?mbda=3A_new_extension_or_not=3F?=
In-Reply-To: <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <26f948c5-4957-48f6-8817-0375889df3c8@www.fastmail.com>

I have voted for extending LambdaCase. I don't think extensions should be immutable, and in this case it's clear that the original extension was incomplete. We should make it complete.

On Wed, Sep 15, 2021, at 08:00, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> Vitaly, Eric, Tom, Alejandro
> As Joachim says, we need to make a decision on the LambdaCase flag 
> issue.  It’s a judgement call, so let’s just vote.
> Here is the voting sheet 
> <https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs/edit?usp=sharing>.  I have filled in votes from Simon, myself, Joacim, Richard, Vlad.  But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two?  It should take you 5 minutes.
> Thanks
> Simon
>  
>  
>  
>  
> 
> PS: I am leaving Microsoft at the end of November 2021, at which point 
> simonpj at microsoft.com will cease to work.  Use 
> simon.peytonjones at gmail.com instead.  (For now, it just forwards to 
> simonpj at microsoft.com.)
> 
>  
> 
> |  -----Original Message-----
> 
> |  From: ghc-steering-committee <ghc-steering-committee-
> 
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> 
> |  Sent: 14 September 2021 08:39
> 
> |  To: ghc-steering-committee at haskell.org
> 
> |  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda:
> 
> |  new extension or not?
> 
> |  
> 
> |  Hi,
> 
> |  
> 
> |  
> 
> |  on the multiway-lambda story, we have voted to add \cases alongside
> 
> |  \case. But one open question is still: Do we
> 
> |   (1) add -XLambdaCases (which would imply -XLambdaCase) or
> 
> |   (2) simply expand the meaning of -XLambdaCase.
> 
> |  
> 
> |  On the Github thread at
> 
> |  
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment- 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  
> 895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  
> 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  
> 20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDY 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDYUKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0>
> 
> |  we see that I lean towards (1), but SPJ leands towards (2).
> 
> |  
> 
> |  It doesn’t matter that much, but we need to make a decision. Can I
> 
> |  please get some opinions from the rest of the committee on this point?
> 
> |  
> 
> |  Cheers,
> 
> |  Joachim
> 
> |  
> 
> |  
> 
> |  --
> 
> |  Joachim Breitner
> 
> |    mail at joachim-breitner.de
> 
> |  
> 
> |  
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  oachim- 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  
> breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  
> 434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  
> 7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec4 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0>
> 
> |  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec421KJYmL9I2ZO%2BlIx5J9cLw27GnmI%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 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  
> committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  
> 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  
> 20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> |  soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

From vlad.z.4096 at gmail.com  Thu Sep 16 16:07:20 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Thu, 16 Sep 2021 19:07:20 +0300
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
	rec: accept
Message-ID: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>

Dear Committee,

Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been submitted for our consideration.

Read it here: https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-complete-set-signatures.rst
Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400

The proposal presents an alternative treatment for type annotations on COMPLETE pragmas. Today one could write

   {-# COMPLETE P, Q :: Either #-}

where P and Q are some pattern synonyms. But this isn’t even well-kinded.

Instead, the author proposes that we ask our users to write

  {-# COMPLETE P, Q :: Either l r #-}

By requiring a proper type on the RHS, we also gain the ability to talk about more advanced use cases (described in the proposal).

I recommend acceptance. In fact, I learned about the way these annotations are treated today only from reading the proposal, and it came as a surprise to me. Using proper, well-kinded types there, seems like the right thing to do even if we ignore the new use cases it enables.

Let me know what you think.

- Vlad

From mail at joachim-breitner.de  Thu Sep 16 16:55:46 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Sep 2021 18:55:46 +0200
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
 rec: accept
In-Reply-To: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
Message-ID: <4431b2e55328334880266ff5d1d689b14a6c5ae1.camel@joachim-breitner.de>

Hi,

very convincing proposal, so I am happy with it.

I’ll ask a minor question about  breaking existing COMPLETE pragmas on
Github.

Cheers,
Joachim

Am Donnerstag, dem 16.09.2021 um 19:07 +0300 schrieb Vladislav Zavialov
(int-index):
> Dear Committee,
> 
> Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been submitted for our consideration.
> 
> Read it here: https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-complete-set-signatures.rst
> Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400
> 
> The proposal presents an alternative treatment for type annotations on COMPLETE pragmas. Today one could write
> 
>    {-# COMPLETE P, Q :: Either #-}
> 
> where P and Q are some pattern synonyms. But this isn’t even well-kinded.
> 
> Instead, the author proposes that we ask our users to write
> 
>   {-# COMPLETE P, Q :: Either l r #-}
> 
> By requiring a proper type on the RHS, we also gain the ability to talk about more advanced use cases (described in the proposal).
> 
> I recommend acceptance. In fact, I learned about the way these annotations are treated today only from reading the proposal, and it came as a surprise to me. Using proper, well-kinded types there, seems like the right thing to do even if we ignore the new use cases it enables.
> 
> Let me know what you think.
> 
> - Vlad
> _______________________________________________
> 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 trupill at gmail.com  Fri Sep 17 07:49:17 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 17 Sep 2021 07:49:17 +0000
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
 rec: accept
In-Reply-To: <4431b2e55328334880266ff5d1d689b14a6c5ae1.camel@joachim-breitner.de>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
 <4431b2e55328334880266ff5d1d689b14a6c5ae1.camel@joachim-breitner.de>
Message-ID: <CAHnFXOt1wL3swDe4Z8MpPYt7v2pXi7qF=HpTJmbP=R_CoAAUiQ@mail.gmail.com>

 Hi,
I am also happy with the proposal. The only thing I could not figure out is
whether changing the COMPLETE sets to the new syntax works also in the old
one. I mean, would a way to ensure compatibility with both current GHC, and
GHC+this proposal to write:

{-# COMPLETE … :: Either l r #-}

Regards,
Alejandro

El 16 sept 2021 18:55:46, Joachim Breitner <mail at joachim-breitner.de>
escribió:

> Hi,
>
> very convincing proposal, so I am happy with it.
>
> I’ll ask a minor question about  breaking existing COMPLETE pragmas on
> Github.
>
> Cheers,
> Joachim
>
> Am Donnerstag, dem 16.09.2021 um 19:07 +0300 schrieb Vladislav Zavialov
> (int-index):
>
> Dear Committee,
>
>
> Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been
> submitted for our consideration.
>
>
> Read it here:
> https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-complete-set-signatures.rst
>
> Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400
>
>
> The proposal presents an alternative treatment for type annotations on
> COMPLETE pragmas. Today one could write
>
>
>    {-# COMPLETE P, Q :: Either #-}
>
>
> where P and Q are some pattern synonyms. But this isn’t even well-kinded.
>
>
> Instead, the author proposes that we ask our users to write
>
>
>   {-# COMPLETE P, Q :: Either l r #-}
>
>
> By requiring a proper type on the RHS, we also gain the ability to talk
> about more advanced use cases (described in the proposal).
>
>
> I recommend acceptance. In fact, I learned about the way these annotations
> are treated today only from reading the proposal, and it came as a surprise
> to me. Using proper, well-kinded types there, seems like the right thing to
> do even if we ignore the new use cases it enables.
>
>
> Let me know what you think.
>
>
> - Vlad
>
> _______________________________________________
>
> 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/20210917/fcc237a2/attachment.html>

From simonpj at microsoft.com  Fri Sep 17 10:25:35 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Sep 2021 10:25:35 +0000
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB02693DCEDCFD290182E631D0ADDD9@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Vitaly, Tom
Are you there?  I'd love to hear from you about this.
Thanks
Simon

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com<mailto:simonpj at microsoft.com> will cease to work.  Use simon.peytonjones at gmail.com<mailto:simon.peytonjones at gmail.com> instead.  (For now, it just forwards to simonpj at microsoft.com.)

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 15 September 2021 13:00
To: ghc-steering-committee at haskell.org
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: [ghc-steering-committee] Proposal #302: Multiway lambda: new extension or not?

Vitaly, Eric, Tom, Alejandro
As Joachim says, we need to make a decision on the LambdaCase flag issue.  It's a judgement call, so let's just vote.
Here is the voting sheet<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277542395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jzU6mlExltnKz2q0FPK%2Bm5wTCqXANQJMD7cmJESk85Q%3D&reserved=0>.  I have filled in votes from Simon, myself, Joacim, Richard, Vlad.  But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two?  It should take you 5 minutes.
Thanks
Simon






PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com<mailto:simonpj at microsoft.com> will cease to work.  Use simon.peytonjones at gmail.com<mailto:simon.peytonjones at gmail.com> instead.  (For now, it just forwards to simonpj at microsoft.com<mailto:simonpj at microsoft.com>.)



|  -----Original Message-----

|  From: ghc-steering-committee <ghc-steering-committee-

|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner

|  Sent: 14 September 2021 08:39

|  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>

|  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda:

|  new extension or not?

|

|  Hi,

|

|

|  on the multiway-lambda story, we have voted to add \cases alongside

|  \case. But one open question is still: Do we

|   (1) add -XLambdaCases (which would imply -XLambdaCase) or

|   (2) simply expand the meaning of -XLambdaCase.

|

|  On the Github thread at

|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0>

|  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0>

|  895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277562383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fz8Ac4%2FZsxyb%2BZTVzPf4vLUrBW2aLyWkHHVk96Kl86Q%3D&reserved=0>

|  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277572379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZvWJy8VOnYChUkEu0Uz3I3i4txgrawqt06KdkKlvdts%3D&reserved=0>

|  20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0>

|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDY<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0>

|  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277592367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W9Rq1zlL1DXKExX%2B2XLVl0olo74BKhF1JuelgGySimI%3D&reserved=0>

|  we see that I lean towards (1), but SPJ leands towards (2).

|

|  It doesn't matter that much, but we need to make a decision. Can I

|  please get some opinions from the rest of the committee on this point?

|

|  Cheers,

|  Joachim

|

|

|  --

|  Joachim Breitner

|    mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>

|

|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0>

|  oachim-<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0>

|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277612365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raBLXrB3GJ2oSrmIysrHs0X%2FtzPlt3hojkvp6v3lVdU%3D&reserved=0>

|  434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0>

|  7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0>

|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec4<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277632352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dNhxQH7oR41rjrD7USKU%2F2Rhm%2Bo2qnQFoKdi3WjoqIc%3D&reserved=0>

|  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277642348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UrzlZdQeq29XEiWbdAeQH%2BGi4%2BpOIqka6IeJ%2BAuJ9qc%3D&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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0>

|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0>

|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277662342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LSFYEN4qQBFd7t4o2CGuEyjUibTaZvdjDgzunCNl2YU%3D&reserved=0>

|  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0>

|  20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0>

|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277682330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=87FhXp16tqtDe3%2BB099uId0JRDBhSf5uaxKC9Lg%2Bh%2BQ%3D&reserved=0>

|  soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277692329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=olFbP%2BA3I3L4lBZxAcO%2FGPS8LqhCBamQC6oo0560lEg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210917/395e45a8/attachment-0001.html>

From bravit111 at gmail.com  Sat Sep 18 09:40:04 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 18 Sep 2021 12:40:04 +0300
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <VI1PR83MB02693DCEDCFD290182E631D0ADDD9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <VI1PR83MB02693DCEDCFD290182E631D0ADDD9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmOnrv_Wbv_v8SAAbFAB53a=qytfe7uA8i88wt2UVnufrQ@mail.gmail.com>

I've voted to extend LambdaCase. I prefer thinking that the backward
incompatibility problem, in this case, is negligible.

Vitaly


пт, 17 сент. 2021 г. в 13:25, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org>:

> Vitaly, Tom
>
> Are you there?  I’d love to hear from you about this.
>
> Thanks
>
> Simon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com
> instead.  (For now, it just forwards to simonpj at microsoft.com.)
>
>
>
> *From:* Simon Peyton Jones <simonpj at microsoft.com>
> *Sent:* 15 September 2021 13:00
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* RE: [ghc-steering-committee] Proposal #302: Multiway lambda:
> new extension or not?
>
>
>
> Vitaly, Eric, Tom, Alejandro
>
> As Joachim says, we need to make a decision on the LambdaCase flag issue.
> It’s a judgement call, so let’s just vote.
>
> Here is the voting sheet
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277542395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jzU6mlExltnKz2q0FPK%2Bm5wTCqXANQJMD7cmJESk85Q%3D&reserved=0>.
> I have filled in votes from Simon, myself, Joacim, Richard, Vlad.  But four
> of us (in the to: line) have not expressed an opinion. Could you do so
> please, in the next day or two?  It should take you 5 minutes.
>
> Thanks
>
> Simon
>
>
>
>
>
>
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com
> instead.  (For now, it just forwards to simonpj at microsoft.com.)
>
>
>
> |  -----Original Message-----
>
> |  From: ghc-steering-committee <ghc-steering-committee-
>
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
>
> |  Sent: 14 September 2021 08:39
>
> |  To: ghc-steering-committee at haskell.org
>
> |  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda:
>
> |  new extension or not?
>
> |
>
> |  Hi,
>
> |
>
> |
>
> |  on the multiway-lambda story, we have voted to add \cases alongside
>
> |  \case. But one open question is still: Do we
>
> |   (1) add -XLambdaCases (which would imply -XLambdaCase) or
>
> |   (2) simply expand the meaning of -XLambdaCase.
>
> |
>
> |  On the Github thread at
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0>
>
> |  ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0>
>
> |  895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277562383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fz8Ac4%2FZsxyb%2BZTVzPf4vLUrBW2aLyWkHHVk96Kl86Q%3D&reserved=0>
>
> |  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277572379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZvWJy8VOnYChUkEu0Uz3I3i4txgrawqt06KdkKlvdts%3D&reserved=0>
>
> |  20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0>
>
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUznezDY
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0>
>
> |  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277592367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W9Rq1zlL1DXKExX%2B2XLVl0olo74BKhF1JuelgGySimI%3D&reserved=0>
>
> |  we see that I lean towards (1), but SPJ leands towards (2).
>
> |
>
> |  It doesn’t matter that much, but we need to make a decision. Can I
>
> |  please get some opinions from the rest of the committee on this point?
>
> |
>
> |  Cheers,
>
> |  Joachim
>
> |
>
> |
>
> |  --
>
> |  Joachim Breitner
>
> |    mail at joachim-breitner.de
>
> |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0>
>
> |  oachim-
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0>
>
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277612365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raBLXrB3GJ2oSrmIysrHs0X%2FtzPlt3hojkvp6v3lVdU%3D&reserved=0>
>
> |  434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0>
>
> |  7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0>
>
> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00ec4
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277632352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dNhxQH7oR41rjrD7USKU%2F2Rhm%2Bo2qnQFoKdi3WjoqIc%3D&reserved=0>
>
> |  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277642348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UrzlZdQeq29XEiWbdAeQH%2BGi4%2BpOIqka6IeJ%2BAuJ9qc%3D&reserved=0>
>
> |
>
> |
>
> |  _______________________________________________
>
> |  ghc-steering-committee mailing list
>
> |  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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0>
>
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0>
>
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277662342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LSFYEN4qQBFd7t4o2CGuEyjUibTaZvdjDgzunCNl2YU%3D&reserved=0>
>
> |  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0>
>
> |  20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0>
>
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173SoM5
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277682330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=87FhXp16tqtDe3%2BB099uId0JRDBhSf5uaxKC9Lg%2Bh%2BQ%3D&reserved=0>
>
> |  soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277692329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=olFbP%2BA3I3L4lBZxAcO%2FGPS8LqhCBamQC6oo0560lEg%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/20210918/26bba217/attachment-0001.html>

From bravit111 at gmail.com  Sat Sep 18 09:46:49 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 18 Sep 2021 12:46:49 +0300
Subject: [ghc-steering-committee] #390: Fine-grained pragmas,
 recommendation: accept
In-Reply-To: <ffeb5d03d01e3dc562dca40a9470dc0992c80837.camel@joachim-breitner.de>
References: <CALpVSmPJDcaPaWNUKrE4gUOatQ0gLj=RQaxi5Ew+R3bxm_P_ww@mail.gmail.com>
 <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com>
 <CALpVSmMKSn3o+0_rzvxUckeEykY_Jk5tGRLBrFf12t1H_bZ0QA@mail.gmail.com>
 <CALpVSmM-hu0rD0euXBy99+kRb2ioR4rc_Haa5=3PX_7sV=VVnQ@mail.gmail.com>
 <010f017a9afd2eea-bbac2727-573e-4423-a5a9-fc69d9b16703-000000@us-east-2.amazonses.com>
 <CAHnFXOspmpv4FTOGPv3gwnZqNRP_o1MdtRjb0TMhMaA6z0u2pg@mail.gmail.com>
 <ffeb5d03d01e3dc562dca40a9470dc0992c80837.camel@joachim-breitner.de>
Message-ID: <CALpVSmNDa9i8OuiYPXicSdd+J6y6F0m_PxzxSK+pyP0CSVJajQ@mail.gmail.com>

Hi Joachim,

Simon PJ had several suggestions here:
https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-889025857.
I believe it's up to Alejandro to either address them in the proposal or
decline.

Vitaly



вт, 14 сент. 2021 г. в 10:47, Joachim Breitner <mail at joachim-breitner.de>:

> Hi Vitaly,
>
> what is the status of this? Richard said he supports acceptance, but I
> am not sure if there are still open questions?
>
> Cheers,
> Joachim
>
> Am Freitag, dem 23.07.2021 um 07:44 +0000 schrieb Alejandro Serrano
> Mena:
> >  Dear all,
> > I’ve just updated the proposal following a great suggestion by Vlad.
> >
> > Unfortunately, I don’t know enough about GHC’s parsing machinery to
> > answer the question posed by Richard. I’ll repeat it in case somebody
> > in the Committee can shed some light on it:
> >
> > > The proposal use ; to separate the modifiers from the declarations.
> > > Combined with the layout rule this allows us to write in two forms:
> > >
> > >
> > >
> > >  > %NoTerminationCheck ; instance C Int where ...
> > >
> > >
> > > > %NoTerminationCheck
> > > > instance C Int where …
> > >
> > > Would it be possible to allow the modifier to simply precede the
> > > `instance` without turning the parser into a mess?
> > >
> >
> > Regards,
> > Alejandro
> >
> > El 12 jul 2021 15:52:01, Richard Eisenberg <lists at richarde.dev>
> > escribió:
> >
> > > I'm happy with this updated proposal, though I've made a small
> > > suggestion about making the ;s optional.
> > >
> > > Regardless of whether this suggestion is taken, I support
> > > acceptance.
> > >
> > > Thanks,
> > > Richard
> > >
> > > > On Jul 4, 2021, at 5:12 AM, Vitaly Bragilevsky
> > > > <bravit111 at gmail.com> wrote:
> > > >
> > > > Dear Committee,
> > > >
> > > > I'm happy to repeat my recommendation to accept Alejandro's
> > > > proposal which is now back from revision:
> > > > Fine-grained pragmas for classes, families, and instances
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > >
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > >
> > > > All the issues that arose in the previous discussion are now
> > > > resolved. Does anyone have something to add?
> > > >
> > > > Vitaly
> > > >
> > > >
> > > >
> > > > сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky
> > > > <bravit111 at gmail.com>:
> > > > > чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index)
> > > > > <vlad.z.4096 at gmail.com>:
> > > > > > I like the proposal and I would be happy to vote for its
> > > > > > acceptance. However, it requires a little bit of polishing up
> > > > > > with regards to its use of modifiers. In particular, it seems
> > > > > > to treat modifiers as built-in units, whereas the core idea
> > > > > > behind modifiers is that they are based on actual promoted
> > > > > > types (with the exception of %1).
> > > > > >
> > > > > > Hence it seems appropriate to send it back for revision until
> > > > > > this point is addressed.
> > > > > >
> > > > >
> > > > >
> > > > > Yes, I agree. There is also another issue. I think we need
> > > > > either a deprecation story for UndecidableInstances, or a
> > > > > statement that it should survive with some motivation behind
> > > > > that.
> > > > >
> > > > > So, I'm sending this proposal back to Alejandro for review and
> > > > > set the "needs revision" label on GitHub.
> > > > >
> > > > > Vitaly
> > > > > >
> > > > > > - Vlad
> > > > > >
> > > > > > > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky
> > > > > > <bravit111 at gmail.com> wrote:
> > > > > > >
> > > > > > > Dear Committee,
> > > > > > >
> > > > > > > Our own Alejandro has been proposed
> > > > > > > Fine-grained pragmas for classes, families, and instances
> > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390
> > > > > > >
> > > > > >
> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md
> > > > > > >
> > > > > > > His idea is to bring the flexibility of
> > > > > > overlaps/overlapping/overlappable pragmas to termination
> > > > > > checking, type inference, and constraint solving. Alejandro
> > > > > > proposes to introduce the following %-modifiers (as in
> > > > > > already
> > > > > > accepted #370,
> > > > > >
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst
> > > > > > ):
> > > > > > > %NoTerminationCheck
> > > > > > > %LiberalCoverage
> > > > > > > %LiberalInjectivity
> > > > > > > %Overlapping
> > > > > > > %Overlappable
> > > > > > > %Overlaps
> > > > > > > to liberate conditions for classes and instances, type
> > > > > > families, forall-types, etc. The first three modifiers can be
> > > > > > used instead of the scary-sounding UndecidableInstances
> > > > > > extension. The last three modifiers are supposed to be used
> > > > > > instead of the  overlap*-pragmas for instances we already
> > > > > > have.
> > > > > > Note that this proposal doesn't suggest deprecating those
> > > > > > extensions and pragmas.
> > > > > > >
> > > > > > > I think that this proposal goes in the right direction and
> > > > > > recommend accepting it.
> > > > > > >
> > > > > > > As far as I understand, all the committee members,
> > > > > > > including
> > > > > > those with terms about to expire, have the right to either
> > > > > > support this proposal or to raise a voice against it either
> > > > > > here or at
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/390.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Vitaly
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > ghc-steering-committee mailing list
> > > > > > > ghc-steering-committee at haskell.org
> > > > > > >
> > > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > >  _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20210918/29f5aba6/attachment.html>

From lists at richarde.dev  Mon Sep 20 20:44:09 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 20 Sep 2021 20:44:09 +0000
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
 rec: accept
In-Reply-To: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
Message-ID: <010f017c04f3a79a-fa667a99-1b3f-4d8c-9490-78b907675314-000000@us-east-2.amazonses.com>

I support acceptance.

Thanks!
Richard

> On Sep 16, 2021, at 12:07 PM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com> wrote:
> 
> Dear Committee,
> 
> Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been submitted for our consideration.
> 
> Read it here: https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-complete-set-signatures.rst
> Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400
> 
> The proposal presents an alternative treatment for type annotations on COMPLETE pragmas. Today one could write
> 
>   {-# COMPLETE P, Q :: Either #-}
> 
> where P and Q are some pattern synonyms. But this isn’t even well-kinded.
> 
> Instead, the author proposes that we ask our users to write
> 
>  {-# COMPLETE P, Q :: Either l r #-}
> 
> By requiring a proper type on the RHS, we also gain the ability to talk about more advanced use cases (described in the proposal).
> 
> I recommend acceptance. In fact, I learned about the way these annotations are treated today only from reading the proposal, and it came as a surprise to me. Using proper, well-kinded types there, seems like the right thing to do even if we ignore the new use cases it enables.
> 
> Let me know what you think.
> 
> - Vlad
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From trupill at gmail.com  Tue Sep 21 11:23:17 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 21 Sep 2021 11:23:17 +0000
Subject: [ghc-steering-committee] Stepping down
Message-ID: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>

Hello everybody,

In the last time I hadn’t had the energy to follow many of the discussions
in this committee, and I don’t think this will change soon, so I would like
to step down from the committee.

If you think it’s OK, I can keep shepherding the proposal which was
assigned to me (NoFallibleDo), since it doesn’t feel right to put that on
somebody else’s shoulders.

Kind regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210921/bfe95b8b/attachment.html>

From simonpj at microsoft.com  Tue Sep 21 11:43:45 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 21 Sep 2021 11:43:45 +0000
Subject: [ghc-steering-committee] Stepping down
In-Reply-To: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>
References: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>
Message-ID: <VI1PR83MB026980D46CEC895E3206E1A8ADA19@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I’ll be sorry to lose you Alejandro!

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com<mailto:simonpj at microsoft.com> will cease to work.  Use simon.peytonjones at gmail.com<mailto:simon.peytonjones at gmail.com> instead.  (For now, it just forwards to simonpj at microsoft.com.)

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 21 September 2021 12:23
To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] Stepping down

Hello everybody,

In the last time I hadn’t had the energy to follow many of the discussions in this committee, and I don’t think this will change soon, so I would like to step down from the committee.

If you think it’s OK, I can keep shepherding the proposal which was assigned to me (NoFallibleDo), since it doesn’t feel right to put that on somebody else’s shoulders.

Kind regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210921/0651bb24/attachment.html>

From lists at richarde.dev  Tue Sep 21 13:29:05 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 21 Sep 2021 13:29:05 +0000
Subject: [ghc-steering-committee] Stepping down
In-Reply-To: <VI1PR83MB026980D46CEC895E3206E1A8ADA19@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>
 <VI1PR83MB026980D46CEC895E3206E1A8ADA19@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <010f017c088bb3c4-13de3330-b629-49c4-a41c-92770934d70c-000000@us-east-2.amazonses.com>

It's been a pleasure to work with you on this committee, Alejandro. Thanks for your work!

Richard

> On Sep 21, 2021, at 7:43 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I’ll be sorry to lose you Alejandro!
>  
> PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com <mailto:simonpj at microsoft.com> will cease to work.  Use simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com> instead.  (For now, it just forwards to simonpj at microsoft.com <mailto:simonpj at microsoft.com>.)
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
> Sent: 21 September 2021 12:23
> To: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: [ghc-steering-committee] Stepping down
>  
> Hello everybody,
>  
> In the last time I hadn’t had the energy to follow many of the discussions in this committee, and I don’t think this will change soon, so I would like to step down from the committee.
>  
> If you think it’s OK, I can keep shepherding the proposal which was assigned to me (NoFallibleDo), since it doesn’t feel right to put that on somebody else’s shoulders.
>  
> Kind regards,
> Alejandro
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Tue Sep 21 15:07:03 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 21 Sep 2021 17:07:03 +0200
Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: new
 extension or not?
In-Reply-To: <CALpVSmOnrv_Wbv_v8SAAbFAB53a=qytfe7uA8i88wt2UVnufrQ@mail.gmail.com>
References: <AM9PR83MB0481153974AE93A09B2A396FAD119@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <AM9PR83MB04819C7051F82C392D2738BFADE49@AM9PR83MB0481.EURPRD83.prod.outlook.com>
 <81dc0b2b8b825356d2daf5ad71c5cc7f3508f019.camel@joachim-breitner.de>
 <VI1PR83MB0269B87A99E46EBB2D4DF088ADDB9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <VI1PR83MB02693DCEDCFD290182E631D0ADDD9@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <CALpVSmOnrv_Wbv_v8SAAbFAB53a=qytfe7uA8i88wt2UVnufrQ@mail.gmail.com>
Message-ID: <1eb9119c4b6110366ffc2b6d64f92bceb00ae957.camel@joachim-breitner.de>

Hi,

accepted, with using -XLambdaCase. Thanks all!

Cheers,
Joachim

Am Samstag, dem 18.09.2021 um 12:40 +0300 schrieb Vitaly Bragilevsky:
> I've voted to extend LambdaCase. I prefer thinking that the backward
> incompatibility problem, in this case, is negligible.
> 
> Vitaly
> 
> 
> пт, 17 сент. 2021 г. в 13:25, Simon Peyton Jones via ghc-steering-
> committee <ghc-steering-committee at haskell.org>:
> > Vitaly, Tom
> > Are you there?  I’d love to hear from you about this.
> > Thanks
> > Simon
> >  
> > PS: I am leaving Microsoft at the end of November 2021, at which
> > pointsimonpj at microsoft.com will cease to work. 
> > Usesimon.peytonjones at gmail.com instead.  (For now, it just forwards
> > to simonpj at microsoft.com.)
> >  
> > From: Simon Peyton Jones <simonpj at microsoft.com>
> > Sent: 15 September 2021 13:00
> > To: ghc-steering-committee at haskell.org
> > Cc: Simon Peyton Jones <simonpj at microsoft.com>
> > Subject: RE: [ghc-steering-committee] Proposal #302: Multiway
> > lambda: new extension or not?
> >  
> > Vitaly, Eric, Tom, Alejandro
> > As Joachim says, we need to make a decision on the LambdaCase flag
> > issue.  It’s a judgement call, so let’s just vote.
> > Here is the voting sheet.  I have filled in votes from Simon,
> > myself, Joacim, Richard, Vlad.  But four of us (in the to: line)
> > have not expressed an opinion. Could you do so please, in the next
> > day or two?  It should take you 5 minutes.
> > Thanks
> > Simon
> >  
> >  
> >  
> >  
> > PS: I am leaving Microsoft at the end of November 2021, at which
> > pointsimonpj at microsoft.com will cease to work. 
> > Usesimon.peytonjones at gmail.com instead.  (For now, it just forwards
> > tosimonpj at microsoft.com.)
> >  
> > |  -----Original Message-----
> > |  From: ghc-steering-committee <ghc-steering-committee-
> > |  bounces at haskell.org> On Behalf Of Joachim Breitner
> > |  Sent: 14 September 2021 08:39
> > |  To: ghc-steering-committee at haskell.org
> > |  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway
> > lambda:
> > |  new extension or not?
> > |  
> > |  Hi,
> > |  
> > |  
> > |  on the multiway-lambda story, we have voted to add \cases
> > alongside
> > |  \case. But one open question is still: Do we
> > |   (1) add -XLambdaCases (which would imply -XLambdaCase) or
> > |   (2) simply expand the meaning of -XLambdaCase.
> > |  
> > |  On the Github thread at
> > | 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > |  ub.com%2Fghc-proposals%2Fghc-
> > proposals%2Fpull%2F302%23issuecomment-
> > | 
> > 895080031&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943
> > 459
> > | 
> > 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376
> > 720
> > | 
> > 20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > uMz
> > | 
> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2ySitCA%2FT1uUzne
> > zDY
> > |  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&amp;reserved=0
> > |  we see that I lean towards (1), but SPJ leands towards (2).
> > |  
> > |  It doesn’t matter that much, but we need to make a decision. Can
> > I
> > |  please get some opinions from the rest of the committee on this
> > point?
> > |  
> > |  Cheers,
> > |  Joachim
> > |  
> > |  
> > |  --
> > |  Joachim Breitner
> > |    mail at joachim-breitner.de
> > |  
> > | 
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> > |  oachim-
> > | 
> > breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88
> > 319
> > | 
> > 434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> > C63
> > | 
> > 7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > oiV
> > | 
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=unmdYu9zUy00
> > ec4
> > |  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&amp;reserved=0
> > |  
> > |  
> > |  _______________________________________________
> > |  ghc-steering-committee mailing list
> > |  ghc-steering-committee at haskell.org
> > | 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > | 
> > committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943
> > 459
> > | 
> > 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376
> > 720
> > | 
> > 20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > uMz
> > | 
> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TG3t%2Fw1kFLk173S
> > oM5
> > |  soHU39BlAPv76TY%2B9FNetaLJs%3D&amp;reserved=0
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From mail at joachim-breitner.de  Tue Sep 21 15:11:15 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 21 Sep 2021 17:11:15 +0200
Subject: [ghc-steering-committee] Stepping down
In-Reply-To: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>
References: <CAHnFXOsW+ZbVnaqQzk2gDFpmq9MyUSzVcVaPDkuJxmVoVGYT2g@mail.gmail.com>
Message-ID: <03b2c1669cdbe84fd4c0735afbec2a02a6b32c24.camel@joachim-breitner.de>

Hi Alejandro,

thanks for your contributions! You brought a lot of energy to the table
for most of the time you were on the committee, and I am grateful for
that.

Also thanks for being reflective about your commitments, and stepping
down before they become a burden for you, and vice versa.

If you want, I suggest you finish shepherding the NoFallibleDo
proposal, and “officially” resign from the committee once that’s done.
I promise to not assign further proposals to you :-)

Cheers,
Joachim

Am Dienstag, dem 21.09.2021 um 11:23 +0000 schrieb Alejandro Serrano
Mena:
> In the last time I hadn’t had the energy to follow many of the
> discussions in this committee, and I don’t think this will change
> soon, so I would like to step down from the committee.
> 
> If you think it’s OK, I can keep shepherding the proposal which was
> assigned to me (NoFallibleDo), since it doesn’t feel right to put
> that on somebody else’s shoulders.
> 
> Kind regards,
> Alejandro
> _______________________________________________
> 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  Wed Sep 22 07:32:27 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 22 Sep 2021 09:32:27 +0200
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
 rec: accept
In-Reply-To: <010f017c04f3a79a-fa667a99-1b3f-4d8c-9490-78b907675314-000000@us-east-2.amazonses.com>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
 <010f017c04f3a79a-fa667a99-1b3f-4d8c-9490-78b907675314-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQnEP8j+D6R+CRVkyUis2qtoTf7bv7OgNdJ4i5kQ4q9Qeg@mail.gmail.com>

I support acceptance as well.

On Mon, Sep 20, 2021 at 10:44 PM Richard Eisenberg <lists at richarde.dev>
wrote:

> I support acceptance.
>
> Thanks!
> Richard
>
> > On Sep 16, 2021, at 12:07 PM, Vladislav Zavialov (int-index) <
> vlad.z.4096 at gmail.com> wrote:
> >
> > Dear Committee,
> >
> > Proposal #400 "COMPLETE set signatures” by Sebastian Graf has been
> submitted for our consideration.
> >
> > Read it here:
> https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/proposals/0000-complete-set-signatures.rst
> > Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/400
> >
> > The proposal presents an alternative treatment for type annotations on
> COMPLETE pragmas. Today one could write
> >
> >   {-# COMPLETE P, Q :: Either #-}
> >
> > where P and Q are some pattern synonyms. But this isn’t even well-kinded.
> >
> > Instead, the author proposes that we ask our users to write
> >
> >  {-# COMPLETE P, Q :: Either l r #-}
> >
> > By requiring a proper type on the RHS, we also gain the ability to talk
> about more advanced use cases (described in the proposal).
> >
> > I recommend acceptance. In fact, I learned about the way these
> annotations are treated today only from reading the proposal, and it came
> as a surprise to me. Using proper, well-kinded types there, seems like the
> right thing to do even if we ignore the new use cases it enables.
> >
> > Let me know what you think.
> >
> > - Vlad
> > _______________________________________________
> > 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/20210922/d945134f/attachment-0001.html>

From simonpj at microsoft.com  Wed Sep 22 21:52:25 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 22 Sep 2021 21:52:25 +0000
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
	rec: accept
In-Reply-To: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
Message-ID: <VI1PR83MB0269D4CCB5526D5933612187ADA29@VI1PR83MB0269.EURPRD83.prod.outlook.com>

I'm in favour of #400.

Simon

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com instead.  (For now, it just forwards to simonpj at microsoft.com.)

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Vladislav Zavialov (int-index)
|  Sent: 16 September 2021 17:07
|  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
|  Subject: [ghc-steering-committee] Proposal #400: COMPLETE set
|  signatures; rec: accept
|  
|  Dear Committee,
|  
|  Proposal #400 "COMPLETE set signatures" by Sebastian Graf has been
|  submitted for our consideration.
|  
|  Read it here:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Fconstrained-complete-
|  sigs%2Fproposals%2F0000-complete-set-
|  signatures.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cccd12e8010
|  654946877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7674053577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=a3j3xlr4FFrJ0%2
|  B6gB80Kb%2FQ%2Faxz0uDyb8HYpLYhNEBg%3D&amp;reserved=0
|  Discussion here:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F400&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccc
|  d12e8010654946877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637674053577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WPnozLD
|  TtXlaFkUPtyZbzGSn5%2BmpqoTRkRhoy6SJqfg%3D&amp;reserved=0
|  
|  The proposal presents an alternative treatment for type annotations on
|  COMPLETE pragmas. Today one could write
|  
|     {-# COMPLETE P, Q :: Either #-}
|  
|  where P and Q are some pattern synonyms. But this isn't even well-
|  kinded.
|  
|  Instead, the author proposes that we ask our users to write
|  
|    {-# COMPLETE P, Q :: Either l r #-}
|  
|  By requiring a proper type on the RHS, we also gain the ability to
|  talk about more advanced use cases (described in the proposal).
|  
|  I recommend acceptance. In fact, I learned about the way these
|  annotations are treated today only from reading the proposal, and it
|  came as a surprise to me. Using proper, well-kinded types there, seems
|  like the right thing to do even if we ignore the new use cases it
|  enables.
|  
|  Let me know what you think.
|  
|  - Vlad
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cccd12e801065494
|  6877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376740
|  53577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VeWjPT7WIwEpivqCypFm
|  5RmWv%2BLTeT%2BmrQUS76UOVPw%3D&amp;reserved=0

From bravit111 at gmail.com  Thu Sep 23 15:35:36 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Thu, 23 Sep 2021 18:35:36 +0300
Subject: [ghc-steering-committee] Proposal #400: COMPLETE set signatures;
 rec: accept
In-Reply-To: <VI1PR83MB0269D4CCB5526D5933612187ADA29@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <7BDEE8EB-C1FD-431E-8A6A-F63BC973A0EF@gmail.com>
 <VI1PR83MB0269D4CCB5526D5933612187ADA29@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmNnRuPu1yd8bFnbANcK0TxU1_Uud7NcXm5pV6WiZn+ydw@mail.gmail.com>

Hi,

I support acceptance.

Vitaly

чт, 23 сент. 2021 г. в 00:53, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org>:

> I'm in favour of #400.
>
> Simon
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simonpj at microsoft.com will cease to work.  Use simon.peytonjones at gmail.com
> instead.  (For now, it just forwards to simonpj at microsoft.com.)
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Vladislav Zavialov (int-index)
> |  Sent: 16 September 2021 17:07
> |  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  Subject: [ghc-steering-committee] Proposal #400: COMPLETE set
> |  signatures; rec: accept
> |
> |  Dear Committee,
> |
> |  Proposal #400 "COMPLETE set signatures" by Sebastian Graf has been
> |  submitted for our consideration.
> |
> |  Read it here:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Fconstrained-complete-
> |  sigs%2Fproposals%2F0000-complete-set-
> |  signatures.rst&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cccd12e8010
> |  654946877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> |  7674053577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=a3j3xlr4FFrJ0%2
> |  B6gB80Kb%2FQ%2Faxz0uDyb8HYpLYhNEBg%3D&amp;reserved=0
> |  Discussion here:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  ub.com%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F400&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccc
> |  d12e8010654946877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637674053577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> |  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WPnozLD
> |  TtXlaFkUPtyZbzGSn5%2BmpqoTRkRhoy6SJqfg%3D&amp;reserved=0
> |
> |  The proposal presents an alternative treatment for type annotations on
> |  COMPLETE pragmas. Today one could write
> |
> |     {-# COMPLETE P, Q :: Either #-}
> |
> |  where P and Q are some pattern synonyms. But this isn't even well-
> |  kinded.
> |
> |  Instead, the author proposes that we ask our users to write
> |
> |    {-# COMPLETE P, Q :: Either l r #-}
> |
> |  By requiring a proper type on the RHS, we also gain the ability to
> |  talk about more advanced use cases (described in the proposal).
> |
> |  I recommend acceptance. In fact, I learned about the way these
> |  annotations are treated today only from reading the proposal, and it
> |  came as a surprise to me. Using proper, well-kinded types there, seems
> |  like the right thing to do even if we ignore the new use cases it
> |  enables.
> |
> |  Let me know what you think.
> |
> |  - Vlad
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cccd12e801065494
> |  6877608d9792c1a90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376740
> |  53577434736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VeWjPT7WIwEpivqCypFm
> |  5RmWv%2BLTeT%2BmrQUS76UOVPw%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/20210923/8e0397b1/attachment.html>