From lists at richarde.dev  Wed Dec  8 21:45:19 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 8 Dec 2021 21:45:19 +0000
Subject: [ghc-steering-committee] #433: the Unsatisfiable constraint;
 recommendation: accept
In-Reply-To: <010f017d71fb3cdb-da54c83c-5997-4b11-8f4a-c4093c0a335d-000000@us-east-2.amazonses.com>
References: <0DE2BE2C-83C4-46CC-9A58-8D7E0E023748@gmail.com>
 <010f017d71fb3cdb-da54c83c-5997-4b11-8f4a-c4093c0a335d-000000@us-east-2.amazonses.com>
Message-ID: <010f017d9c020b26-e35b0190-280b-4ebc-a36c-816bfda7a593-000000@us-east-2.amazonses.com>

From Tom's recommendation, this proposal has now been accepted. Thanks, all!

Richard

> On Nov 30, 2021, at 12:53 PM, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> +1
> 
>> On Nov 30, 2021, at 8:37 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> Since I last emailed the committee, Adam has split the proposal into two parts: one for `Unsatisfiable` and one for `Warning`. I think I’m right in saying that everyone who has voiced an opinion has been in favour of the `Unsatisfiable` half, so if no one has any further thoughts, I suggest we accept this half and continue discussing `Warning` later on.
>> 
>> Thanks,
>> Tom
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simon.peytonjones at gmail.com  Fri Dec 10 16:51:20 2021
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 10 Dec 2021 16:51:20 +0000
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>

Dear Steering Committee

I'd like to propose that we accept Proposal #452: Articulate principles for
GHC evolution

   - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452
   - Proposal:
   https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst

Remember, we are not debating the principles themselves, all of which are
embodied in earlier proposals.  Rather we are discussing

   - the usefulness of having  a place where we articulate the principles,
   and
   - a process for updating them over time, namely by PRs against this
   proposal

The idea is that the latest incarnation of the proposal is always the
current set of agreed principles.

Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll
take silence as assent, unless a big discussion arises.

Thanks

Simon

On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev> wrote:

> Dear Committee,
>
> This is your interim secretary speaking:
>
> Articulate principles for GHC evolution, proposing a new "principles"
> document to be added to the proposals repo, has been proposed by me.
> https://github.com/ghc-proposals/ghc-proposals/pull/452
> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>
> I propose Simon PJ as the shepherd, as this is something of a
> meta-proposal, appropriate for shepherding by our chair.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211210/bf87c480/attachment.html>

From trupill at gmail.com  Sun Dec 12 12:07:41 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sun, 12 Dec 2021 07:07:41 -0500
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
Message-ID: <CAHnFXOtgmpeNKfna3xU1DWTXTiWkHAOC-utqskPOrxi=mBk1zA@mail.gmail.com>

 I am happy with the proposal. My only suggestion is to include a patch to
the main README.md in the repo which links to this particular proposal.
This would increase discoverability for those who arrive to the
‘ghc-proposals’ repo for the first time.

Alejandro

El 10 dic 2021 17:51:20, Simon Peyton Jones <simon.peytonjones at gmail.com>
escribió:

> Dear Steering Committee
>
> I'd like to propose that we accept Proposal #452: Articulate principles
> for GHC evolution
>
>    - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452
>    - Proposal:
>    https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>
> Remember, we are not debating the principles themselves, all of which are
> embodied in earlier proposals.  Rather we are discussing
>
>    - the usefulness of having  a place where we articulate the
>    principles, and
>    - a process for updating them over time, namely by PRs against this
>    proposal
>
> The idea is that the latest incarnation of the proposal is always the
> current set of agreed principles.
>
> Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll
> take silence as assent, unless a big discussion arises.
>
> Thanks
>
> Simon
>
> On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> Dear Committee,
>>
>> This is your interim secretary speaking:
>>
>> Articulate principles for GHC evolution, proposing a new "principles"
>> document to be added to the proposals repo, has been proposed by me.
>> https://github.com/ghc-proposals/ghc-proposals/pull/452
>> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>>
>> I propose Simon PJ as the shepherd, as this is something of a
>> meta-proposal, appropriate for shepherding by our chair.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211212/e51774c2/attachment.html>

From lists at richarde.dev  Sun Dec 12 19:19:16 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Sun, 12 Dec 2021 19:19:16 +0000
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAHnFXOtgmpeNKfna3xU1DWTXTiWkHAOC-utqskPOrxi=mBk1zA@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
 <CAHnFXOtgmpeNKfna3xU1DWTXTiWkHAOC-utqskPOrxi=mBk1zA@mail.gmail.com>
Message-ID: <010f017db015c588-eea5d5bb-18fc-4c31-be41-960946a97308-000000@us-east-2.amazonses.com>

Good point! I have pushed this change.

Thanks,
Richard

> On Dec 12, 2021, at 7:07 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> I am happy with the proposal. My only suggestion is to include a patch to the main README.md in the repo which links to this particular proposal. This would increase discoverability for those who arrive to the ‘ghc-proposals’ repo for the first time.
> 
> Alejandro
> 
> El 10 dic 2021 17:51:20, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> escribió:
>> Dear Steering Committee
>> 
>> I'd like to propose that we accept Proposal #452: Articulate principles for GHC evolution
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452 <https://github.com/ghc-proposals/ghc-proposals/pull/452>
>> Proposal:  https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst <https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst>
>> Remember, we are not debating the principles themselves, all of which are embodied in earlier proposals.  Rather we are discussing 
>> the usefulness of having  a place where we articulate the principles, and
>> a process for updating them over time, namely by PRs against this proposal
>> The idea is that the latest incarnation of the proposal is always the current set of agreed principles.
>> 
>> Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll take silence as assent, unless a big discussion arises.
>> 
>> Thanks
>> 
>> Simon
>> 
>> On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>> Dear Committee,
>> 
>> This is your interim secretary speaking:
>> 
>> Articulate principles for GHC evolution, proposing a new "principles" document to be added to the proposals repo, has been proposed by me.
>> https://github.com/ghc-proposals/ghc-proposals/pull/452 <https://github.com/ghc-proposals/ghc-proposals/pull/452>
>> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst <https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst>
>> 
>> I propose Simon PJ as the shepherd, as this is something of a meta-proposal, appropriate for shepherding by our chair.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> 
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From eric at seidel.io  Sun Dec 12 20:24:49 2021
From: eric at seidel.io (Eric Seidel)
Date: Sun, 12 Dec 2021 15:24:49 -0500
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
Message-ID: <d41653b1-959a-40c0-a2a5-612c48266dac@www.fastmail.com>

Writing down our design principles in one place makes a lot of sense to me, +1

On Fri, Dec 10, 2021, at 11:51, Simon Peyton Jones wrote:
> Dear Steering Committee
>
> I'd like to propose that we accept Proposal #452: Articulate principles 
> for GHC evolution
>  * Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452
>  * Proposal:  
> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
> Remember, we are not debating the principles themselves, all of which 
> are embodied in earlier proposals.  Rather we are discussing 
>  * the usefulness of having  a place where we articulate the 
> principles, and 
>  * a process for updating them over time, namely by PRs against this 
> proposal
> The idea is that the latest incarnation of the proposal is always the 
> current set of agreed principles.
>
> Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll 
> take silence as assent, unless a big discussion arises.
>
> Thanks
>
> Simon
>
> On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev> wrote:
>> Dear Committee,
>> 
>> This is your interim secretary speaking:
>> 
>> Articulate principles for GHC evolution, proposing a new "principles" document to be added to the proposals repo, has been proposed by me.
>> https://github.com/ghc-proposals/ghc-proposals/pull/452
>> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>> 
>> I propose Simon PJ as the shepherd, as this is something of a meta-proposal, appropriate for shepherding by our chair.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> 
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From arnaud.spiwack at tweag.io  Mon Dec 13 07:46:45 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 13 Dec 2021 08:46:45 +0100
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <d41653b1-959a-40c0-a2a5-612c48266dac@www.fastmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
 <d41653b1-959a-40c0-a2a5-612c48266dac@www.fastmail.com>
Message-ID: <CAH6fHQmL90SRer0k7WAF80DMtj=99h_F2+Zv=8QxSYqc2at8Sg@mail.gmail.com>

This is all reasonable. When crafting this response my main question was:
“is this the right place for such overarching principles”. To which my
answer was (almost immediately, I've got to admit) “of course it is the
right place for this”. The fact that the document encourages proposals to
modify the document when relevant is good evidence of it. And more
generally, these principles live where design happens; it all makes sense.

/Arnaud

On Sun, Dec 12, 2021 at 9:25 PM Eric Seidel <eric at seidel.io> wrote:

> Writing down our design principles in one place makes a lot of sense to
> me, +1
>
> On Fri, Dec 10, 2021, at 11:51, Simon Peyton Jones wrote:
> > Dear Steering Committee
> >
> > I'd like to propose that we accept Proposal #452: Articulate principles
> > for GHC evolution
> >  * Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452
> >  * Proposal:
> >
> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
> > Remember, we are not debating the principles themselves, all of which
> > are embodied in earlier proposals.  Rather we are discussing
> >  * the usefulness of having  a place where we articulate the
> > principles, and
> >  * a process for updating them over time, namely by PRs against this
> > proposal
> > The idea is that the latest incarnation of the proposal is always the
> > current set of agreed principles.
> >
> > Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll
> > take silence as assent, unless a big discussion arises.
> >
> > Thanks
> >
> > Simon
> >
> > On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev>
> wrote:
> >> Dear Committee,
> >>
> >> This is your interim secretary speaking:
> >>
> >> Articulate principles for GHC evolution, proposing a new "principles"
> document to be added to the proposals repo, has been proposed by me.
> >> https://github.com/ghc-proposals/ghc-proposals/pull/452
> >>
> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
> >>
> >> I propose Simon PJ as the shepherd, as this is something of a
> meta-proposal, appropriate for shepherding by our chair.
> >>
> >> Please guide us to a conclusion as outlined in
> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>
> >> Thanks,
> >> Richard
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211213/0f223cba/attachment-0001.html>

From mail at joachim-breitner.de  Wed Dec 15 20:44:51 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 15 Dec 2021 21:44:51 +0100
Subject: [ghc-steering-committee] Please review #460: migration plan for
 non-magical-~ Shepherd: Richard
Message-ID: <1a4686b2da6c1b8209020605942c79d24c6a81ce.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking (who is back from travels):

Vlad proposed an amendment to #371 (Export ~ from Data.Type.Equality)
to improve the migration plan

https://github.com/ghc-proposals/ghc-proposals/pull/460

Following the tradition that amendments are shepherded by the same
shepherd as the original proposal, this falls on Richard.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim


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



From mail at joachim-breitner.de  Wed Dec 15 20:46:47 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 15 Dec 2021 21:46:47 +0100
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
Message-ID: <bb1fc15d5ce11ed3ca234e9ca074780d62f791f2.camel@joachim-breitner.de>

:thumbsup:

Am Freitag, dem 10.12.2021 um 16:51 +0000 schrieb Simon Peyton Jones:
> Dear Steering Committee
> 
> I'd like to propose that we accept Proposal #452: Articulate
> principles for GHC evolution
>  * Discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/452
>  * Proposal: 
> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
> Remember, we are not debating the principles themselves, all of which
> are embodied in earlier proposals.  Rather we are discussing 
>  * the usefulness of having  a place where we articulate the
> principles, and 
>  * a process for updating them over time, namely by PRs against this
> proposal
> The idea is that the latest incarnation of the proposal is always the
> current set of agreed principles.
> 
> Please respond by Friday 17 Dec. Because it seems uncontroversial,
> I'll take silence as assent, unless a big discussion arises.
> 
> Thanks
> 
> Simon
> 
> On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev>
> wrote:
> > Dear Committee,
> > 
> > This is your interim secretary speaking:
> > 
> > Articulate principles for GHC evolution, proposing a new
> > "principles" document to be added to the proposals repo, has been
> > proposed by me.
> > https://github.com/ghc-proposals/ghc-proposals/pull/452https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
> > 
> > I propose Simon PJ as the shepherd, as this is something of a meta-
> > proposal, appropriate for shepherding by our chair.
> > 
> > Please guide us to a conclusion as outlined in 
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > 
> > Thanks,
> > Richard
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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



From mail at joachim-breitner.de  Wed Dec 15 21:05:23 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 15 Dec 2021 22:05:23 +0100
Subject: [ghc-steering-committee] GHC Steering Committee Status
Message-ID: <f3970d86055258b354a4de71a445dbde06802daf.camel@joachim-breitner.de>

Dear Committee,

I hope you all had a lovely fall. Three months since the last status
mail! High time for a new one.

So what has happened since the last one?

 * Simon suggested a better way to keep tabs on what’s going on, and
   you’ll find the second have of this mail at
   https://github.com/ghc-proposals/ghc-proposals/wiki/Status 

   I still didn’t get around to mess with markdown tables etc… sorry. 
   If someone feels inspired for how that wiki page would look better,
   ideally with markup that I can easily edit and include in this 
   email, suggestions are welcome.

 * Alejandro announced to step down once through with his currently
   shepherded proposals.

 * We decided to not define GHC2022.

 * we were asked to review these proposals:
  
   #433: the Unsatisfiable constraint
   #452: Articulate principles for GHC evolution
   #451: Sized literals proposal
   #460: migration plan for non-magical-~
  
 * we have a recommendation from the shepherd about:

   #400: COMPLETE set signatures; rec: accept
   #425: invisible binders in type declarations; rec: accept
   #433: the Unsatisfiable constraint; recommendation: accept

 * we have sent the following proposals back to revision

   #412: Explicit Splice Imports
   #400: COMPLETE set signatures
   #283: Local modules

 * we decided about the following proposals

   #302: Multiway lambda (accept)
   #409: Exportable named defaults (accept)
   #281: Visible "forall" in terms (accept)
   #433: the Unsatisfiable constraint; recommendation: accept

We currently have to act on the following 6 proposals, down by 3:

## Waiting for committee decision

#452: Articulate principles for GHC evolution (Shepherd: SPJ)
      2021-12-15: Ongoing discussion, heading for acceptance

#425: Invisible binders in type declarations, Shepherd: Richard
      2021-10-19: Recommendation to accept

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

#319: NoFallibleDo, Shepherd: Alejandro
      2021-07-23: Rejection recommended
      Continued silence since the last update.
      Committee comments please?

## Waiting for Shepherd action

#451: Sized Literals, Shepherd: Simon M.
      2021-11-19: Assigned to Simon M.
      Simon, what do you think of this?

#460: migration plan for non-magical-~, Shepherd: Richard
      2021-12-15: Assigned to Richard



Cheers,
Joachim



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



From trupill at gmail.com  Fri Dec 17 09:48:24 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 17 Dec 2021 01:48:24 -0800
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
Message-ID: <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>

 Dear all,
I missed it back then, but the authors of the “NoFallibleDo” proposal have
re-submitted to the Committee.

It seems though that we are still in some form of impasse, without leaning
towards acceptance or rejection. From the discussion, I think that the
feeling is that this is a desirable feature, but there are different
opinions about whether this should be per-module or per-block. It would be
great if all of us would discuss this matter (either here or in the GitHub
thread) and try to come to a conclusion (or ultimately cast a vote to
decide).

The proposal itself is about being able to tweak whether an incomplete
pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
leading to an additional MonadFail constraint — or works as any other
pattern match — leading to a PatternMatchFail exception when a non-matching
value comes there.

Once again, I would love to hear your opinions :)

Regards,
Alejandro


El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
escribió:

> I’ve been made aware that the “NoFallibleDo” proposal has been
> re-submitted to the Committee. My current recommendation is “reject”, as
> outlined in the following comment
> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
> you’d often like to enable this for a particular “do” block, not for an
> entire file).
>
> Regards,
> Alejandro
>
>
> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
> escribió:
>
>> Done. Once again, sorry for the confusion.
>>
>> Alejandro
>>
>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>> simonpj at microsoft.com>) escribió:
>>
>>> OK, so to summarise
>>>
>>>    - We are waiting for the author
>>>    - You are encouraging us to comment anyway
>>>
>>>
>>> Correct?  Does the author know this?   Why encourage only us?   Maybe
>>> post on Github to clarify the status, and encourage everyone to contribute.
>>>
>>>
>>>
>>> S
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 28 July 2020 10:25
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>
>>>
>>>
>>> I mean the last status, push back to the author for revision.
>>>
>>>
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>> simonpj at microsoft.com>) escribió:
>>>
>>> So I’m still confused.  “We went back to GIthub”… does that mean that we
>>> invited the author to revise and resubmit?  I don’t know what else “back to
>>> github” means.
>>>
>>>
>>>
>>> If it’s in committee-decision status, then our process says  should
>>> either accept, reject, or push back to the author for revision, in a timely
>>> way (guided by the shepherd)
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 28 July 2020 10:22
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>
>>>
>>>
>>> Eric was initially in charge, but I took over his duties. He thought
>>> that a bit more discussion was needed, something I agree with, so we went
>>> back to GitHub.
>>>
>>>
>>>
>>> Sorry about the stale status, I feel that my back-and-forth was not very
>>> clear.
>>>
>>>
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>> simonpj at microsoft.com>) escribió:
>>>
>>> Alejandro, this one hasn’t been on my radar.
>>>
>>>
>>>
>>> Are you the shepherd?   Have you made a recommendation?  Is the proposal
>>> in its final form  -- ie having absorbed all discussion etc?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>> Serrano Mena
>>> *Sent:* 28 July 2020 09:22
>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>
>>>
>>>
>>> Dear Committee,
>>>
>>> I would like to kindly ask for your input in the NoFallibleDo proposal
>>> -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>
>>> This was submitted, then there was some discussion, but the conversation
>>> has stalled.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>> trupill at gmail.com>) escribió:
>>>
>>> @Eric congratulations! enjoy! :)
>>>
>>>
>>>
>>> @Joachim I can take care of this, I think the direction Eric was pushing
>>> this is a good one.
>>>
>>>
>>>
>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>> mail at joachim-breitner.de>) escribió:
>>>
>>> Hi,
>>>
>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>> > My wife and I just checked into the hospital to have our second child
>>>
>>> Congrats, and all the best!
>>>
>>> > , so I’m going to be short on time for committee duties for a few
>>> > weeks. I think it would be best to reassign this proposal so we don’t
>>> > keep the authors waiting.
>>>
>>> Any volunteers?
>>>
>>> Cheers,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211217/4ce58fdd/attachment.html>

From arnaud.spiwack at tweag.io  Fri Dec 17 13:35:22 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 17 Dec 2021 14:35:22 +0100
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
Message-ID: <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>

To recapitulate, this proposal remarks that GHC does a
pre-pattern-matching-exhaustiveness check during the renaming phase to
figure out how whether it needs to insert fail in do-notation statements of
the form C x1… xn <- u. It notes that this precheck is heuristic, and
decides whether a MonadFail constraint will be required during type
checking. It argues that this is bad because you may end up being asked for
a MonadFail constraint when you were careful to write an exhaustive pattern
dependent on a GADT’s argument. And that it is a fundamental limitation of
the current desugaring scheme.

All these observations look correct (and were validated, in the PR’s
discussion by Sebastian Graf who is quite well-versed in the relevant parts
of the code). The argument that it is a bad thing is relatable (heuristic
in type checking are generally undesirable).

The proposal’s solution is to add an extension which would switch the
desugaring of C x1… xn <- u statements to never use fail (instead throw an
imprecise exception like regular case expressions). And have
incomplete-pattern-matching warnings. Basically treating <- like a let in
this context. I think.

The problem I see with this solution is that, while it can be argued that
it would have been desirable to do just that at the inception of Haskell,
it is quite unlikely that we can ever make this the default (considering
how much code exists that rely on the current fail-based desugaring, and
how hard it would be to track). So such an extension would remain as a
switch forever. And I don’t find that it’s particularly worth it.
------------------------------

John Ericsson, who is one of the co-author of the proposal, also wrote a
companion proposal https://github.com/ghc-proposals/ghc-proposals/pull/327
In this second proposal, he introduces a new statement form for the do
notation: case C x1 … xn <- u of { alts }, such that

do
  { case C x1 … xn <- u of { alts }
  ; stmts }

desugars to

do
  case u of
  { C x1 … xn -> do { stmts }
  ; alts }

The proposal is still marked as WIP, but the general idea is reasonable.
This is intended as a replacement of the fail desugaring, by inserting fail
(or whatever you see fit) manually: case C x1 … xn <- u of { _ -> fail }.

But, from my point of view, this proposal could just as well serve as a
replacement of the NoFailibleDo proposal being discussed in this thread.
Since you could force a fail-free pattern-matching as case C x1 … xn <- u
of {}.

I personally find this direction much more compelling.

/Arnaud

On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Dear all,
> I missed it back then, but the authors of the “NoFallibleDo” proposal have
> re-submitted to the Committee.
>
> It seems though that we are still in some form of impasse, without leaning
> towards acceptance or rejection. From the discussion, I think that the
> feeling is that this is a desirable feature, but there are different
> opinions about whether this should be per-module or per-block. It would be
> great if all of us would discuss this matter (either here or in the GitHub
> thread) and try to come to a conclusion (or ultimately cast a vote to
> decide).
>
> The proposal itself is about being able to tweak whether an incomplete
> pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
> leading to an additional MonadFail constraint — or works as any other
> pattern match — leading to a PatternMatchFail exception when a non-matching
> value comes there.
>
> Once again, I would love to hear your opinions :)
>
> Regards,
> Alejandro
>
>
> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
> escribió:
>
>> I’ve been made aware that the “NoFallibleDo” proposal has been
>> re-submitted to the Committee. My current recommendation is “reject”, as
>> outlined in the following comment
>> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
>> you’d often like to enable this for a particular “do” block, not for an
>> entire file).
>>
>> Regards,
>> Alejandro
>>
>>
>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
>> escribió:
>>
>>> Done. Once again, sorry for the confusion.
>>>
>>> Alejandro
>>>
>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>>> simonpj at microsoft.com>) escribió:
>>>
>>>> OK, so to summarise
>>>>
>>>>    - We are waiting for the author
>>>>    - You are encouraging us to comment anyway
>>>>
>>>>
>>>> Correct?  Does the author know this?   Why encourage only us?   Maybe
>>>> post on Github to clarify the status, and encourage everyone to contribute.
>>>>
>>>>
>>>>
>>>> S
>>>>
>>>>
>>>>
>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>> *Sent:* 28 July 2020 10:25
>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>> *Cc:* ghc-steering-committee at haskell.org
>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>
>>>>
>>>>
>>>> I mean the last status, push back to the author for revision.
>>>>
>>>>
>>>>
>>>> Alejandro
>>>>
>>>>
>>>>
>>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>>> simonpj at microsoft.com>) escribió:
>>>>
>>>> So I’m still confused.  “We went back to GIthub”… does that mean that
>>>> we invited the author to revise and resubmit?  I don’t know what else “back
>>>> to github” means.
>>>>
>>>>
>>>>
>>>> If it’s in committee-decision status, then our process says  should
>>>> either accept, reject, or push back to the author for revision, in a timely
>>>> way (guided by the shepherd)
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>> *Sent:* 28 July 2020 10:22
>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>> *Cc:* ghc-steering-committee at haskell.org
>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>
>>>>
>>>>
>>>> Eric was initially in charge, but I took over his duties. He thought
>>>> that a bit more discussion was needed, something I agree with, so we went
>>>> back to GitHub.
>>>>
>>>>
>>>>
>>>> Sorry about the stale status, I feel that my back-and-forth was not
>>>> very clear.
>>>>
>>>>
>>>>
>>>> Alejandro
>>>>
>>>>
>>>>
>>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>>> simonpj at microsoft.com>) escribió:
>>>>
>>>> Alejandro, this one hasn’t been on my radar.
>>>>
>>>>
>>>>
>>>> Are you the shepherd?   Have you made a recommendation?  Is the
>>>> proposal in its final form  -- ie having absorbed all discussion etc?
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* ghc-steering-committee <
>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>> Serrano Mena
>>>> *Sent:* 28 July 2020 09:22
>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>
>>>>
>>>>
>>>> Dear Committee,
>>>>
>>>> I would like to kindly ask for your input in the NoFallibleDo proposal
>>>> -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>>
>>>> This was submitted, then there was some discussion, but the
>>>> conversation has stalled.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Alejandro
>>>>
>>>>
>>>>
>>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>>> trupill at gmail.com>) escribió:
>>>>
>>>> @Eric congratulations! enjoy! :)
>>>>
>>>>
>>>>
>>>> @Joachim I can take care of this, I think the direction Eric was
>>>> pushing this is a good one.
>>>>
>>>>
>>>>
>>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>>> mail at joachim-breitner.de>) escribió:
>>>>
>>>> Hi,
>>>>
>>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>>> > My wife and I just checked into the hospital to have our second child
>>>>
>>>> Congrats, and all the best!
>>>>
>>>> > , so I’m going to be short on time for committee duties for a few
>>>> > weeks. I think it would be best to reassign this proposal so we don’t
>>>> > keep the authors waiting.
>>>>
>>>> Any volunteers?
>>>>
>>>> Cheers,
>>>> Joachim
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%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/20211217/e64fe396/attachment-0001.html>

From trupill at gmail.com  Fri Dec 17 16:55:58 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 17 Dec 2021 08:55:58 -0800
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
 <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
Message-ID: <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>

 Thanks for your great summary, Arnaud!

These are the possible outcomes I see here: could you add your opinions /
vote?

A. Accept the proposal as-is,
B. Request further changes,
C. Reject the proposal and direct the authors towards proposal #327.

Regards,
Alejandro

El 17 dic 2021 14:35:22, "Spiwack, Arnaud" <arnaud.spiwack at tweag.io>
escribió:

> To recapitulate, this proposal remarks that GHC does a
> pre-pattern-matching-exhaustiveness check during the renaming phase to
> figure out how whether it needs to insert fail in do-notation statements
> of the form C x1… xn <- u. It notes that this precheck is heuristic, and
> decides whether a MonadFail constraint will be required during type
> checking. It argues that this is bad because you may end up being asked for
> a MonadFail constraint when you were careful to write an exhaustive
> pattern dependent on a GADT’s argument. And that it is a fundamental
> limitation of the current desugaring scheme.
>
> All these observations look correct (and were validated, in the PR’s
> discussion by Sebastian Graf who is quite well-versed in the relevant parts
> of the code). The argument that it is a bad thing is relatable (heuristic
> in type checking are generally undesirable).
>
> The proposal’s solution is to add an extension which would switch the
> desugaring of C x1… xn <- u statements to never use fail (instead throw
> an imprecise exception like regular case expressions). And have
> incomplete-pattern-matching warnings. Basically treating <- like a let in
> this context. I think.
>
> The problem I see with this solution is that, while it can be argued that
> it would have been desirable to do just that at the inception of Haskell,
> it is quite unlikely that we can ever make this the default (considering
> how much code exists that rely on the current fail-based desugaring, and
> how hard it would be to track). So such an extension would remain as a
> switch forever. And I don’t find that it’s particularly worth it.
> ------------------------------
>
> John Ericsson, who is one of the co-author of the proposal, also wrote a
> companion proposal https://github.com/ghc-proposals/ghc-proposals/pull/327
> In this second proposal, he introduces a new statement form for the do
> notation: case C x1 … xn <- u of { alts }, such that
>
> do
>   { case C x1 … xn <- u of { alts }
>   ; stmts }
>
> desugars to
>
> do
>   case u of
>   { C x1 … xn -> do { stmts }
>   ; alts }
>
> The proposal is still marked as WIP, but the general idea is reasonable.
> This is intended as a replacement of the fail desugaring, by inserting
> fail (or whatever you see fit) manually: case C x1 … xn <- u of { _ ->
> fail }.
>
> But, from my point of view, this proposal could just as well serve as a
> replacement of the NoFailibleDo proposal being discussed in this thread.
> Since you could force a fail-free pattern-matching as case C x1 … xn <- u
> of {}.
>
> I personally find this direction much more compelling.
>
> /Arnaud
>
> On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> Dear all,
>> I missed it back then, but the authors of the “NoFallibleDo” proposal
>> have re-submitted to the Committee.
>>
>> It seems though that we are still in some form of impasse, without
>> leaning towards acceptance or rejection. From the discussion, I think that
>> the feeling is that this is a desirable feature, but there are different
>> opinions about whether this should be per-module or per-block. It would be
>> great if all of us would discuss this matter (either here or in the GitHub
>> thread) and try to come to a conclusion (or ultimately cast a vote to
>> decide).
>>
>> The proposal itself is about being able to tweak whether an incomplete
>> pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
>> leading to an additional MonadFail constraint — or works as any other
>> pattern match — leading to a PatternMatchFail exception when a non-matching
>> value comes there.
>>
>> Once again, I would love to hear your opinions :)
>>
>> Regards,
>> Alejandro
>>
>>
>> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
>> escribió:
>>
>>> I’ve been made aware that the “NoFallibleDo” proposal has been
>>> re-submitted to the Committee. My current recommendation is “reject”, as
>>> outlined in the following comment
>>> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
>>> you’d often like to enable this for a particular “do” block, not for an
>>> entire file).
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
>>> escribió:
>>>
>>>> Done. Once again, sorry for the confusion.
>>>>
>>>> Alejandro
>>>>
>>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>>>> simonpj at microsoft.com>) escribió:
>>>>
>>>>> OK, so to summarise
>>>>>
>>>>>    - We are waiting for the author
>>>>>    - You are encouraging us to comment anyway
>>>>>
>>>>>
>>>>> Correct?  Does the author know this?   Why encourage only us?   Maybe
>>>>> post on Github to clarify the status, and encourage everyone to contribute.
>>>>>
>>>>>
>>>>>
>>>>> S
>>>>>
>>>>>
>>>>>
>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>> *Sent:* 28 July 2020 10:25
>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>
>>>>>
>>>>>
>>>>> I mean the last status, push back to the author for revision.
>>>>>
>>>>>
>>>>>
>>>>> Alejandro
>>>>>
>>>>>
>>>>>
>>>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>>>> simonpj at microsoft.com>) escribió:
>>>>>
>>>>> So I’m still confused.  “We went back to GIthub”… does that mean that
>>>>> we invited the author to revise and resubmit?  I don’t know what else “back
>>>>> to github” means.
>>>>>
>>>>>
>>>>>
>>>>> If it’s in committee-decision status, then our process says  should
>>>>> either accept, reject, or push back to the author for revision, in a timely
>>>>> way (guided by the shepherd)
>>>>>
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>> *Sent:* 28 July 2020 10:22
>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>
>>>>>
>>>>>
>>>>> Eric was initially in charge, but I took over his duties. He thought
>>>>> that a bit more discussion was needed, something I agree with, so we went
>>>>> back to GitHub.
>>>>>
>>>>>
>>>>>
>>>>> Sorry about the stale status, I feel that my back-and-forth was not
>>>>> very clear.
>>>>>
>>>>>
>>>>>
>>>>> Alejandro
>>>>>
>>>>>
>>>>>
>>>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>>>> simonpj at microsoft.com>) escribió:
>>>>>
>>>>> Alejandro, this one hasn’t been on my radar.
>>>>>
>>>>>
>>>>>
>>>>> Are you the shepherd?   Have you made a recommendation?  Is the
>>>>> proposal in its final form  -- ie having absorbed all discussion etc?
>>>>>
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> *From:* ghc-steering-committee <
>>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>>> Serrano Mena
>>>>> *Sent:* 28 July 2020 09:22
>>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>
>>>>>
>>>>>
>>>>> Dear Committee,
>>>>>
>>>>> I would like to kindly ask for your input in the NoFallibleDo proposal
>>>>> -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>>>
>>>>> This was submitted, then there was some discussion, but the
>>>>> conversation has stalled.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alejandro
>>>>>
>>>>>
>>>>>
>>>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>>>> trupill at gmail.com>) escribió:
>>>>>
>>>>> @Eric congratulations! enjoy! :)
>>>>>
>>>>>
>>>>>
>>>>> @Joachim I can take care of this, I think the direction Eric was
>>>>> pushing this is a good one.
>>>>>
>>>>>
>>>>>
>>>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>>>> mail at joachim-breitner.de>) escribió:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>>>> > My wife and I just checked into the hospital to have our second child
>>>>>
>>>>> Congrats, and all the best!
>>>>>
>>>>> > , so I’m going to be short on time for committee duties for a few
>>>>> > weeks. I think it would be best to reassign this proposal so we don’t
>>>>> > keep the authors waiting.
>>>>>
>>>>> Any volunteers?
>>>>>
>>>>> Cheers,
>>>>> Joachim
>>>>> --
>>>>> Joachim Breitner
>>>>>   mail at joachim-breitner.de
>>>>>   http://www.joachim-breitner.de/
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%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/20211217/92c3cd53/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Dec 17 17:00:05 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 17 Dec 2021 18:00:05 +0100
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
 <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
 <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
Message-ID: <CAH6fHQkLx3z-HoMqV=PHfdmTwJw2Ssb_UWO4fHuSxqODESbfAw@mail.gmail.com>

I'm in favour of C (and that's all)

I'll be on holiday in a few minutes. Talk to you all again in January :) .

/Arnaud

On Fri, Dec 17, 2021 at 5:55 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Thanks for your great summary, Arnaud!
>
> These are the possible outcomes I see here: could you add your opinions /
> vote?
>
> A. Accept the proposal as-is,
> B. Request further changes,
> C. Reject the proposal and direct the authors towards proposal #327.
>
> Regards,
> Alejandro
>
> El 17 dic 2021 14:35:22, "Spiwack, Arnaud" <arnaud.spiwack at tweag.io>
> escribió:
>
>> To recapitulate, this proposal remarks that GHC does a
>> pre-pattern-matching-exhaustiveness check during the renaming phase to
>> figure out how whether it needs to insert fail in do-notation statements
>> of the form C x1… xn <- u. It notes that this precheck is heuristic, and
>> decides whether a MonadFail constraint will be required during type
>> checking. It argues that this is bad because you may end up being asked for
>> a MonadFail constraint when you were careful to write an exhaustive
>> pattern dependent on a GADT’s argument. And that it is a fundamental
>> limitation of the current desugaring scheme.
>>
>> All these observations look correct (and were validated, in the PR’s
>> discussion by Sebastian Graf who is quite well-versed in the relevant parts
>> of the code). The argument that it is a bad thing is relatable (heuristic
>> in type checking are generally undesirable).
>>
>> The proposal’s solution is to add an extension which would switch the
>> desugaring of C x1… xn <- u statements to never use fail (instead throw
>> an imprecise exception like regular case expressions). And have
>> incomplete-pattern-matching warnings. Basically treating <- like a let
>> in this context. I think.
>>
>> The problem I see with this solution is that, while it can be argued that
>> it would have been desirable to do just that at the inception of Haskell,
>> it is quite unlikely that we can ever make this the default (considering
>> how much code exists that rely on the current fail-based desugaring, and
>> how hard it would be to track). So such an extension would remain as a
>> switch forever. And I don’t find that it’s particularly worth it.
>> ------------------------------
>>
>> John Ericsson, who is one of the co-author of the proposal, also wrote a
>> companion proposal
>> https://github.com/ghc-proposals/ghc-proposals/pull/327
>> In this second proposal, he introduces a new statement form for the do
>> notation: case C x1 … xn <- u of { alts }, such that
>>
>> do
>>   { case C x1 … xn <- u of { alts }
>>   ; stmts }
>>
>> desugars to
>>
>> do
>>   case u of
>>   { C x1 … xn -> do { stmts }
>>   ; alts }
>>
>> The proposal is still marked as WIP, but the general idea is reasonable.
>> This is intended as a replacement of the fail desugaring, by inserting
>> fail (or whatever you see fit) manually: case C x1 … xn <- u of { _ ->
>> fail }.
>>
>> But, from my point of view, this proposal could just as well serve as a
>> replacement of the NoFailibleDo proposal being discussed in this thread.
>> Since you could force a fail-free pattern-matching as case C x1 … xn <-
>> u of {}.
>>
>> I personally find this direction much more compelling.
>>
>> /Arnaud
>>
>> On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <
>> trupill at gmail.com> wrote:
>>
>>> Dear all,
>>> I missed it back then, but the authors of the “NoFallibleDo” proposal
>>> have re-submitted to the Committee.
>>>
>>> It seems though that we are still in some form of impasse, without
>>> leaning towards acceptance or rejection. From the discussion, I think that
>>> the feeling is that this is a desirable feature, but there are different
>>> opinions about whether this should be per-module or per-block. It would be
>>> great if all of us would discuss this matter (either here or in the GitHub
>>> thread) and try to come to a conclusion (or ultimately cast a vote to
>>> decide).
>>>
>>> The proposal itself is about being able to tweak whether an incomplete
>>> pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
>>> leading to an additional MonadFail constraint — or works as any other
>>> pattern match — leading to a PatternMatchFail exception when a non-matching
>>> value comes there.
>>>
>>> Once again, I would love to hear your opinions :)
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
>>> escribió:
>>>
>>>> I’ve been made aware that the “NoFallibleDo” proposal has been
>>>> re-submitted to the Committee. My current recommendation is “reject”, as
>>>> outlined in the following comment
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
>>>> you’d often like to enable this for a particular “do” block, not for an
>>>> entire file).
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>>
>>>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
>>>> escribió:
>>>>
>>>>> Done. Once again, sorry for the confusion.
>>>>>
>>>>> Alejandro
>>>>>
>>>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>>>>> simonpj at microsoft.com>) escribió:
>>>>>
>>>>>> OK, so to summarise
>>>>>>
>>>>>>    - We are waiting for the author
>>>>>>    - You are encouraging us to comment anyway
>>>>>>
>>>>>>
>>>>>> Correct?  Does the author know this?   Why encourage only us?   Maybe
>>>>>> post on Github to clarify the status, and encourage everyone to contribute.
>>>>>>
>>>>>>
>>>>>>
>>>>>> S
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>> *Sent:* 28 July 2020 10:25
>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> I mean the last status, push back to the author for revision.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>
>>>>>> So I’m still confused.  “We went back to GIthub”… does that mean that
>>>>>> we invited the author to revise and resubmit?  I don’t know what else “back
>>>>>> to github” means.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If it’s in committee-decision status, then our process says  should
>>>>>> either accept, reject, or push back to the author for revision, in a timely
>>>>>> way (guided by the shepherd)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>> *Sent:* 28 July 2020 10:22
>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> Eric was initially in charge, but I took over his duties. He thought
>>>>>> that a bit more discussion was needed, something I agree with, so we went
>>>>>> back to GitHub.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sorry about the stale status, I feel that my back-and-forth was not
>>>>>> very clear.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>
>>>>>> Alejandro, this one hasn’t been on my radar.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are you the shepherd?   Have you made a recommendation?  Is the
>>>>>> proposal in its final form  -- ie having absorbed all discussion etc?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* ghc-steering-committee <
>>>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>>>> Serrano Mena
>>>>>> *Sent:* 28 July 2020 09:22
>>>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear Committee,
>>>>>>
>>>>>> I would like to kindly ask for your input in the NoFallibleDo
>>>>>> proposal -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>>>>
>>>>>> This was submitted, then there was some discussion, but the
>>>>>> conversation has stalled.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>>>>> trupill at gmail.com>) escribió:
>>>>>>
>>>>>> @Eric congratulations! enjoy! :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> @Joachim I can take care of this, I think the direction Eric was
>>>>>> pushing this is a good one.
>>>>>>
>>>>>>
>>>>>>
>>>>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>>>>> mail at joachim-breitner.de>) escribió:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>>>>> > My wife and I just checked into the hospital to have our second
>>>>>> child
>>>>>>
>>>>>> Congrats, and all the best!
>>>>>>
>>>>>> > , so I’m going to be short on time for committee duties for a few
>>>>>> > weeks. I think it would be best to reassign this proposal so we
>>>>>> don’t
>>>>>> > keep the authors waiting.
>>>>>>
>>>>>> Any volunteers?
>>>>>>
>>>>>> Cheers,
>>>>>> Joachim
>>>>>> --
>>>>>> Joachim Breitner
>>>>>>   mail at joachim-breitner.de
>>>>>>   http://www.joachim-breitner.de/
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%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/20211217/16d1cfb8/attachment-0001.html>

From lists at richarde.dev  Fri Dec 17 20:14:20 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 17 Dec 2021 20:14:20 +0000
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
 <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
 <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
Message-ID: <010f017dca07fbaf-2e06be66-bb15-415c-a09d-0df16c7ede0b-000000@us-east-2.amazonses.com>

I vote C > B > A, where the further changes requested are to make this decision more locally than at the module level.

I will write more directly on the GitHub thread, because I actually think this proposal is essentially subsumed already.

Richard

> On Dec 17, 2021, at 11:55 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Thanks for your great summary, Arnaud!
> 
> These are the possible outcomes I see here: could you add your opinions / vote?
> 
> A. Accept the proposal as-is,
> B. Request further changes,
> C. Reject the proposal and direct the authors towards proposal #327.
> 
> Regards,
> Alejandro
> 
> El 17 dic 2021 14:35:22, "Spiwack, Arnaud" <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> escribió:
>> To recapitulate, this proposal remarks that GHC does a pre-pattern-matching-exhaustiveness check during the renaming phase to figure out how whether it needs to insert fail in do-notation statements of the form C x1… xn <- u. It notes that this precheck is heuristic, and decides whether a MonadFail constraint will be required during type checking. It argues that this is bad because you may end up being asked for a MonadFail constraint when you were careful to write an exhaustive pattern dependent on a GADT’s argument. And that it is a fundamental limitation of the current desugaring scheme.
>> 
>> All these observations look correct (and were validated, in the PR’s discussion by Sebastian Graf who is quite well-versed in the relevant parts of the code). The argument that it is a bad thing is relatable (heuristic in type checking are generally undesirable).
>> 
>> The proposal’s solution is to add an extension which would switch the desugaring of C x1… xn <- u statements to never use fail (instead throw an imprecise exception like regular case expressions). And have incomplete-pattern-matching warnings. Basically treating <- like a let in this context. I think.
>> 
>> The problem I see with this solution is that, while it can be argued that it would have been desirable to do just that at the inception of Haskell, it is quite unlikely that we can ever make this the default (considering how much code exists that rely on the current fail-based desugaring, and how hard it would be to track). So such an extension would remain as a switch forever. And I don’t find that it’s particularly worth it.
>> 
>> John Ericsson, who is one of the co-author of the proposal, also wrote a companion proposal https://github.com/ghc-proposals/ghc-proposals/pull/327 <https://github.com/ghc-proposals/ghc-proposals/pull/327>
>> In this second proposal, he introduces a new statement form for the do notation: case C x1 … xn <- u of { alts }, such that
>> 
>> do
>>   { case C x1 … xn <- u of { alts }
>>   ; stmts }
>> desugars to
>> 
>> do
>>   case u of
>>   { C x1 … xn -> do { stmts }
>>   ; alts }
>> The proposal is still marked as WIP, but the general idea is reasonable. This is intended as a replacement of the fail desugaring, by inserting fail (or whatever you see fit) manually: case C x1 … xn <- u of { _ -> fail }.
>> 
>> But, from my point of view, this proposal could just as well serve as a replacement of the NoFailibleDo proposal being discussed in this thread. Since you could force a fail-free pattern-matching as case C x1 … xn <- u of {}.
>> 
>> I personally find this direction much more compelling.
>> 
>> /Arnaud
>> 
>> 
>> On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
>> Dear all,
>> I missed it back then, but the authors of the “NoFallibleDo” proposal have re-submitted to the Committee.
>> 
>> It seems though that we are still in some form of impasse, without leaning towards acceptance or rejection. From the discussion, I think that the feeling is that this is a desirable feature, but there are different opinions about whether this should be per-module or per-block. It would be great if all of us would discuss this matter (either here or in the GitHub thread) and try to come to a conclusion (or ultimately cast a vote to decide).
>> 
>> The proposal itself is about being able to tweak whether an incomplete pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now, leading to an additional MonadFail constraint — or works as any other pattern match — leading to a PatternMatchFail exception when a non-matching value comes there.
>> 
>> Once again, I would love to hear your opinions :)
>> 
>> Regards,
>> Alejandro
>> 
>> 
>> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> escribió:
>>> I’ve been made aware that the “NoFallibleDo” proposal has been re-submitted to the Committee. My current recommendation is “reject”, as outlined in the following comment https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 <https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010> (TL;DR, you’d often like to enable this for a particular “do” block, not for an entire file).
>>> 
>>> Regards,
>>> Alejandro
>>> 
>>> 
>>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> escribió:
>>> Done. Once again, sorry for the confusion.
>>> 
>>> Alejandro
>>> 
>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<simonpj at microsoft.com <mailto:simonpj at microsoft.com>>) escribió:
>>> OK, so to summarise
>>> 
>>> We are waiting for the author
>>> You are encouraging us to comment anyway
>>> 
>>> Correct?  Does the author know this?   Why encourage only us?   Maybe post on Github to clarify the status, and encourage everyone to contribute.
>>> 
>>>  
>>> 
>>> S
>>> 
>>>  
>>> 
>>> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> 
>>> Sent: 28 July 2020 10:25
>>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>>> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> Subject: Re: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
>>> 
>>>  
>>> 
>>> I mean the last status, push back to the author for revision.
>>> 
>>>  
>>> 
>>> Alejandro
>>> 
>>>  
>>> 
>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<simonpj at microsoft.com <mailto:simonpj at microsoft.com>>) escribió:
>>> 
>>> So I’m still confused.  “We went back to GIthub”… does that mean that we invited the author to revise and resubmit?  I don’t know what else “back to github” means.
>>> 
>>>  
>>> 
>>> If it’s in committee-decision status, then our process says  should either accept, reject, or push back to the author for revision, in a timely way (guided by the shepherd)
>>> 
>>>  
>>> 
>>> Simon
>>> 
>>>  
>>> 
>>> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> 
>>> Sent: 28 July 2020 10:22
>>> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>>> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> Subject: Re: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
>>> 
>>>  
>>> 
>>> Eric was initially in charge, but I took over his duties. He thought that a bit more discussion was needed, something I agree with, so we went back to GitHub.
>>> 
>>>  
>>> 
>>> Sorry about the stale status, I feel that my back-and-forth was not very clear.
>>> 
>>>  
>>> 
>>> Alejandro
>>> 
>>>  
>>> 
>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<simonpj at microsoft.com <mailto:simonpj at microsoft.com>>) escribió:
>>> 
>>> Alejandro, this one hasn’t been on my radar.
>>> 
>>>  
>>> 
>>> Are you the shepherd?   Have you made a recommendation?  Is the proposal in its final form  -- ie having absorbed all discussion etc?
>>> 
>>>  
>>> 
>>> Simon
>>> 
>>>  
>>> 
>>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
>>> Sent: 28 July 2020 09:22
>>> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>>> Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>>> Subject: Re: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
>>> 
>>>  
>>> 
>>> Dear Committee,
>>> 
>>> I would like to kindly ask for your input in the NoFallibleDo proposal -> https://github.com/ghc-proposals/ghc-proposals/pull/319 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>> This was submitted, then there was some discussion, but the conversation has stalled.
>>> 
>>>  
>>> 
>>> Regards,
>>> 
>>> Alejandro
>>> 
>>>  
>>> 
>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<trupill at gmail.com <mailto:trupill at gmail.com>>) escribió:
>>> 
>>> @Eric congratulations! enjoy! :)
>>> 
>>>  
>>> 
>>> @Joachim I can take care of this, I think the direction Eric was pushing this is a good one.
>>> 
>>>  
>>> 
>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>) escribió:
>>> 
>>> Hi,
>>> 
>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>> > My wife and I just checked into the hospital to have our second child
>>> 
>>> Congrats, and all the best!
>>> 
>>> > , so I’m going to be short on time for committee duties for a few
>>> > weeks. I think it would be best to reassign this proposal so we don’t
>>> > keep the authors waiting. 
>>> 
>>> Any volunteers?
>>> 
>>> Cheers,
>>> Joachim
>>> -- 
>>> Joachim Breitner
>>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>>   http://www.joachim-breitner.de/ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0>_______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20211217/4e8cc98a/attachment-0001.html>

From lists at richarde.dev  Fri Dec 17 22:18:35 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 17 Dec 2021 22:18:35 +0000
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
Message-ID: <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>

I've updated the proposal to include an optional semicolon: https://github.com/goldfirere/ghc-proposals/blob/clarify-modifiers/proposals/0370-modifiers.rst

Richard

> On Jul 26, 2021, at 1:45 PM, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> I like the idea of allowing the semicolon, but I believe it should be optional, as I stated on GitHub: https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938 <https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938>
> 
> I'm content to add the (optional) semicolon to #392.
> 
> I don't know about the practical ramifications. Vlad may be best positioned to answer that.
> 
> Richard
> 
>> On Jul 23, 2021, at 3:53 AM, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
>> 
>> Dear all,
>> Richard has now updated the proposal, but only Arnaud has commented on it. I think this requires a few more eyes, since it will permeate the language once people start using linear types, and we are already thinking about introducing modifiers in other parts.
>> 
>> In fact, I’ve realised that there’s a (grammar) conflict between this proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 <https://github.com/ghc-proposals/ghc-proposals/pull/390> (the fine-grained pragmas for type classes and instances). This proposal defines
>> 
>> topdecl ::= {modifier} 'type' simpletype '=' type
>> | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving]
>> | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving]
>> | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls]
>> | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls]
>> 
>> But #390 defines (note the ; at the end of the modifiers block):
>> 
>> modifiers : {- empty -} | ('%' qtycon)* ';'
>> cl_decl : modifiers 'class' tycl_hdr fds where_cls
>> 
>> I guess we should sort this out before accepting any of them.
>> 
>> Alejandro
>> 
>> El 28 jun 2021 21:26:45, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> escribió:
>> Richard, will you take care of making those small changes to the proposal? That way we could mark this as accepted.
>> 
>> Regards,
>> Alejandro
>> 
>> El 28 jun 2021 9:01:28, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> escribió:
>> Yes, I believe that Richard and I are in agreement now. I don't think all the conclusions have been added to the proposal yet, though; but whatever's left, it's fairly minor.
>> 
>> On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
>> Dear all,
>> This discussion has been dormant for some time, but it’s time to revive it!
>> 
>> Richard, Arnaud, did you manage to reach conclusion about the modification to the proposal?
>> 
>> Apart from that, is there any other concern about the proposal? As I said in my original message, this is a very small amendment to an already-existing proposal, so if we accepted the previous one I see no problem in this one. I’ll wait until Richard and Arnaud get back on the issue, and then assume that silence for a week is acceptance.
>> 
>> Regards,
>> Alejandro
>> 
>> El 11 jun 2021 14:55:41, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> escribió:
>> I think that my discussion with Richard has come to a conclusion (it should incur a small modification to the proposal).
>> 
>> It is a very small (amendment to a) proposal, let's find a consensus on this one quickly.
>> 
>> 
>> On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> I've commented on the PR [ https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189 <https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189> ] the changes on the syntax of lambda expressions are not motivated at all, I think at the very least there should be a discussion in the Alternatives section.
>> 
>> But mostly, I'm worried about the implications/interactions that these changes have with linear types.
>> 
>> (I'll be off for the rest of the week starting tonight, so I'll be back on this conversation on Monday, most likely)
>> 
>> On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
>> Dear Committee,
>> This proposal seems a natural extension of #370, covering some additional cases (modifiers to classes and other declarations) that we’ve found along the way. My recommendation is acceptance.
>> 
>> Regards,
>> Alejandro
>> 
>> On 4 May 2021 at 09:41:56, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> Dear Committe,
>> 
>> Clarify modifiers design principle
>> has been proposed by Richard
>> https://github.com/ghc-proposals/ghc-proposals/pull/392 <https://github.com/ghc-proposals/ghc-proposals/pull/392>
>> 
>> This is an amendmend to #370, see the PR description for links to diffs
>> etc.
>> 
>> I propose Alejandro as the shepherd, as he shepherded #370 before.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> 
>> Thanks,
>> Joachim
>> -- 
>> -- 
>> Joachim Breitner
>>  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20211217/7a746272/attachment.html>

From lists at richarde.dev  Fri Dec 17 22:38:58 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 17 Dec 2021 22:38:58 +0000
Subject: [ghc-steering-committee] #460: better migration for non-magical ~
Message-ID: <010f017dca8c653a-f4181dc8-1e4c-4a72-8637-10f3082c5dc5-000000@us-east-2.amazonses.com>

Hi all,

I am shepherding Proposal #460, an amendment to accepted proposal #371.

#371 proposed making the ~ operator completely non-magical in parsing, behaving syntactically like any other operator. It would have to be imported (though it would be exported from the Prelude, so most users get it for free), -XTypeOperators would have to be enabled, and its appearance is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but only very weakly: I gave a soft recommendation to accept, which Simon PJ trusted (but without much independent confirmation, it seems), Joachim gave a weak accept, and Alejandro and Arnaud said things mildly against (but did not quite vote for rejection).

Text for accepted proposal #371: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-non-magical-eq.md

This current #460 is a small amendment to #371 that makes the migration story gentler. All current programs would continue to be accepted for 8 releases. If ~ is used in a file without TypeOperators, a warning (enabled by default) triggers, saying that the user should enable TypeOperators. This fix is backward compatible. If ~ is used when it is out of scope (say, because a module does not import the Prelude), a warning (in -Wcompat) triggers. The fix is not backward compatible, because (~) is not currently exported from the Prelude. This warning gets moved from -Wcompat to the default warning set after 2 releases.

The previous migration story had no warning for a missing -XTypeOperators, meaning that some code would break immediately (although the fix is easy and backward compatible).

Text for amended proposal: https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals/0371-non-magical-eq.md
Amendment diff: https://github.com/ghc-proposals/ghc-proposals/pull/460/files

---

I recommend acceptance, because immediate breakage of code is bad: it causes kinks in the update cycle after a GHC release. This new migration story should be gentler, and poses little implementation burden.

Given the minor nature of this proposal, I will accept in one week if there is not dissent.

Thanks,
Richard

From mail at joachim-breitner.de  Fri Dec 17 22:47:14 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 17 Dec 2021 23:47:14 +0100
Subject: [ghc-steering-committee] #460: better migration for non-magical
 ~
In-Reply-To: <010f017dca8c653a-f4181dc8-1e4c-4a72-8637-10f3082c5dc5-000000@us-east-2.amazonses.com>
References: <010f017dca8c653a-f4181dc8-1e4c-4a72-8637-10f3082c5dc5-000000@us-east-2.amazonses.com>
Message-ID: <9859376d97e6f31134851887659f67eb10fba8f4.camel@joachim-breitner.de>

Am Freitag, dem 17.12.2021 um 22:38 +0000 schrieb Richard Eisenberg:
> I recommend acceptance, because immediate breakage of code is bad: it causes kinks in the update cycle after a GHC release. This new migration story should be gentler, and poses little implementation burden.
> 


This sounds like a well-thought-through refinement, thanks Vlad, and I
am happy to follow Richard’s recommendation.

Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Fri Dec 17 23:23:52 2021
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 17 Dec 2021 23:23:52 +0000
Subject: [ghc-steering-committee] #460: better migration for non-magical
	~
In-Reply-To: <010f017dca8c653a-f4181dc8-1e4c-4a72-8637-10f3082c5dc5-000000@us-east-2.amazonses.com>
References: <010f017dca8c653a-f4181dc8-1e4c-4a72-8637-10f3082c5dc5-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9CkJrgwz9Koca3xjQmdshnX+7nApHcYo3R9aA6GHgAxw@mail.gmail.com>

I trust Richard (again).  Happy to support this.   Thank you Vlad for this
attention to detail.

Simon

On Fri, 17 Dec 2021 at 22:39, Richard Eisenberg <lists at richarde.dev> wrote:

> Hi all,
>
> I am shepherding Proposal #460, an amendment to accepted proposal #371.
>
> #371 proposed making the ~ operator completely non-magical in parsing,
> behaving syntactically like any other operator. It would have to be
> imported (though it would be exported from the Prelude, so most users get
> it for free), -XTypeOperators would have to be enabled, and its appearance
> is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but
> only very weakly: I gave a soft recommendation to accept, which Simon PJ
> trusted (but without much independent confirmation, it seems), Joachim gave
> a weak accept, and Alejandro and Arnaud said things mildly against (but did
> not quite vote for rejection).
>
> Text for accepted proposal #371:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-non-magical-eq.md
>
> This current #460 is a small amendment to #371 that makes the migration
> story gentler. All current programs would continue to be accepted for 8
> releases. If ~ is used in a file without TypeOperators, a warning (enabled
> by default) triggers, saying that the user should enable TypeOperators.
> This fix is backward compatible. If ~ is used when it is out of scope (say,
> because a module does not import the Prelude), a warning (in -Wcompat)
> triggers. The fix is not backward compatible, because (~) is not currently
> exported from the Prelude. This warning gets moved from -Wcompat to the
> default warning set after 2 releases.
>
> The previous migration story had no warning for a missing -XTypeOperators,
> meaning that some code would break immediately (although the fix is easy
> and backward compatible).
>
> Text for amended proposal:
> https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals/0371-non-magical-eq.md
> Amendment diff:
> https://github.com/ghc-proposals/ghc-proposals/pull/460/files
>
> ---
>
> I recommend acceptance, because immediate breakage of code is bad: it
> causes kinks in the update cycle after a GHC release. This new migration
> story should be gentler, and poses little implementation burden.
>
> Given the minor nature of this proposal, I will accept in one week if
> there is not dissent.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211217/f8309f4b/attachment.html>

From trupill at gmail.com  Thu Dec 23 12:51:40 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 23 Dec 2021 12:51:40 +0000
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <010f017dca07fbaf-2e06be66-bb15-415c-a09d-0df16c7ede0b-000000@us-east-2.amazonses.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
 <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
 <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
 <010f017dca07fbaf-2e06be66-bb15-415c-a09d-0df16c7ede0b-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOtXwqgv3H9cVaVvTyuzU_PqDpr+rGQytE0PqJsic4bYPQ@mail.gmail.com>

 Any further comments? Otherwise my plan is to write back to the authors
next Wednesday with (C) as the outcome: reject the proposal, and direct the
authors to proposal #327.

Alejandro

El 17 dic 2021 21:14:20, Richard Eisenberg <lists at richarde.dev> escribió:

> I vote C > B > A, where the further changes requested are to make this
> decision more locally than at the module level.
>
> I will write more directly on the GitHub thread, because I actually think
> this proposal is essentially subsumed already.
>
> Richard
>
> On Dec 17, 2021, at 11:55 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> Thanks for your great summary, Arnaud!
>
> These are the possible outcomes I see here: could you add your opinions /
> vote?
>
> A. Accept the proposal as-is,
> B. Request further changes,
> C. Reject the proposal and direct the authors towards proposal #327.
>
> Regards,
> Alejandro
>
> El 17 dic 2021 14:35:22, "Spiwack, Arnaud" <arnaud.spiwack at tweag.io>
> escribió:
>
>> To recapitulate, this proposal remarks that GHC does a
>> pre-pattern-matching-exhaustiveness check during the renaming phase to
>> figure out how whether it needs to insert fail in do-notation statements
>> of the form C x1… xn <- u. It notes that this precheck is heuristic, and
>> decides whether a MonadFail constraint will be required during type
>> checking. It argues that this is bad because you may end up being asked for
>> a MonadFail constraint when you were careful to write an exhaustive
>> pattern dependent on a GADT’s argument. And that it is a fundamental
>> limitation of the current desugaring scheme.
>>
>> All these observations look correct (and were validated, in the PR’s
>> discussion by Sebastian Graf who is quite well-versed in the relevant parts
>> of the code). The argument that it is a bad thing is relatable (heuristic
>> in type checking are generally undesirable).
>>
>> The proposal’s solution is to add an extension which would switch the
>> desugaring of C x1… xn <- u statements to never use fail (instead throw
>> an imprecise exception like regular case expressions). And have
>> incomplete-pattern-matching warnings. Basically treating <- like a let
>> in this context. I think.
>>
>> The problem I see with this solution is that, while it can be argued that
>> it would have been desirable to do just that at the inception of Haskell,
>> it is quite unlikely that we can ever make this the default (considering
>> how much code exists that rely on the current fail-based desugaring, and
>> how hard it would be to track). So such an extension would remain as a
>> switch forever. And I don’t find that it’s particularly worth it.
>> ------------------------------
>>
>> John Ericsson, who is one of the co-author of the proposal, also wrote a
>> companion proposal
>> https://github.com/ghc-proposals/ghc-proposals/pull/327
>> In this second proposal, he introduces a new statement form for the do
>> notation: case C x1 … xn <- u of { alts }, such that
>>
>> do
>>   { case C x1 … xn <- u of { alts }
>>   ; stmts }
>>
>> desugars to
>>
>> do
>>   case u of
>>   { C x1 … xn -> do { stmts }
>>   ; alts }
>>
>> The proposal is still marked as WIP, but the general idea is reasonable.
>> This is intended as a replacement of the fail desugaring, by inserting
>> fail (or whatever you see fit) manually: case C x1 … xn <- u of { _ ->
>> fail }.
>>
>> But, from my point of view, this proposal could just as well serve as a
>> replacement of the NoFailibleDo proposal being discussed in this thread.
>> Since you could force a fail-free pattern-matching as case C x1 … xn <-
>> u of {}.
>>
>> I personally find this direction much more compelling.
>>
>> /Arnaud
>>
>> On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <
>> trupill at gmail.com> wrote:
>>
>>> Dear all,
>>> I missed it back then, but the authors of the “NoFallibleDo” proposal
>>> have re-submitted to the Committee.
>>>
>>> It seems though that we are still in some form of impasse, without
>>> leaning towards acceptance or rejection. From the discussion, I think that
>>> the feeling is that this is a desirable feature, but there are different
>>> opinions about whether this should be per-module or per-block. It would be
>>> great if all of us would discuss this matter (either here or in the GitHub
>>> thread) and try to come to a conclusion (or ultimately cast a vote to
>>> decide).
>>>
>>> The proposal itself is about being able to tweak whether an incomplete
>>> pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
>>> leading to an additional MonadFail constraint — or works as any other
>>> pattern match — leading to a PatternMatchFail exception when a non-matching
>>> value comes there.
>>>
>>> Once again, I would love to hear your opinions :)
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
>>> escribió:
>>>
>>>> I’ve been made aware that the “NoFallibleDo” proposal has been
>>>> re-submitted to the Committee. My current recommendation is “reject”, as
>>>> outlined in the following comment
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
>>>> you’d often like to enable this for a particular “do” block, not for an
>>>> entire file).
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>>
>>>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
>>>> escribió:
>>>>
>>>>> Done. Once again, sorry for the confusion.
>>>>>
>>>>> Alejandro
>>>>>
>>>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>>>>> simonpj at microsoft.com>) escribió:
>>>>>
>>>>>> OK, so to summarise
>>>>>>
>>>>>>    - We are waiting for the author
>>>>>>    - You are encouraging us to comment anyway
>>>>>>
>>>>>>
>>>>>> Correct?  Does the author know this?   Why encourage only us?   Maybe
>>>>>> post on Github to clarify the status, and encourage everyone to contribute.
>>>>>>
>>>>>>
>>>>>>
>>>>>> S
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>> *Sent:* 28 July 2020 10:25
>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> I mean the last status, push back to the author for revision.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>
>>>>>> So I’m still confused.  “We went back to GIthub”… does that mean that
>>>>>> we invited the author to revise and resubmit?  I don’t know what else “back
>>>>>> to github” means.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If it’s in committee-decision status, then our process says  should
>>>>>> either accept, reject, or push back to the author for revision, in a timely
>>>>>> way (guided by the shepherd)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>> *Sent:* 28 July 2020 10:22
>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> Eric was initially in charge, but I took over his duties. He thought
>>>>>> that a bit more discussion was needed, something I agree with, so we went
>>>>>> back to GitHub.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sorry about the stale status, I feel that my back-and-forth was not
>>>>>> very clear.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>
>>>>>> Alejandro, this one hasn’t been on my radar.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are you the shepherd?   Have you made a recommendation?  Is the
>>>>>> proposal in its final form  -- ie having absorbed all discussion etc?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* ghc-steering-committee <
>>>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>>>> Serrano Mena
>>>>>> *Sent:* 28 July 2020 09:22
>>>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear Committee,
>>>>>>
>>>>>> I would like to kindly ask for your input in the NoFallibleDo
>>>>>> proposal -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>>>>
>>>>>> This was submitted, then there was some discussion, but the
>>>>>> conversation has stalled.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>>
>>>>>>
>>>>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>>>>> trupill at gmail.com>) escribió:
>>>>>>
>>>>>> @Eric congratulations! enjoy! :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> @Joachim I can take care of this, I think the direction Eric was
>>>>>> pushing this is a good one.
>>>>>>
>>>>>>
>>>>>>
>>>>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>>>>> mail at joachim-breitner.de>) escribió:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>>>>> > My wife and I just checked into the hospital to have our second
>>>>>> child
>>>>>>
>>>>>> Congrats, and all the best!
>>>>>>
>>>>>> > , so I’m going to be short on time for committee duties for a few
>>>>>> > weeks. I think it would be best to reassign this proposal so we
>>>>>> don’t
>>>>>> > keep the authors waiting.
>>>>>>
>>>>>> Any volunteers?
>>>>>>
>>>>>> Cheers,
>>>>>> Joachim
>>>>>> --
>>>>>> Joachim Breitner
>>>>>>   mail at joachim-breitner.de
>>>>>>   http://www.joachim-breitner.de/
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0>
>>>>>>
>>>>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211223/4b1d153c/attachment-0001.html>

From trupill at gmail.com  Thu Dec 23 14:41:26 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 23 Dec 2021 14:41:26 +0000
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
 <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>

 Dear Committee,

As far as I understand, the proposal now allows annotations before
classes/instances/types/… to appear either in its own line or before the
thing, by making semicolons optional (which would be introduced during
parsing if we use a newline).

I think the proposal is ready for acceptance, if no more problems pop up.

Regards,
Alejandro


El 17 dic 2021 23:18:35, Richard Eisenberg <lists at richarde.dev> escribió:

> I've updated the proposal to include an optional semicolon:
> https://github.com/goldfirere/ghc-proposals/blob/clarify-modifiers/proposals/0370-modifiers.rst
>
> Richard
>
> On Jul 26, 2021, at 1:45 PM, Richard Eisenberg <lists at richarde.dev> wrote:
>
> I like the idea of allowing the semicolon, but I believe it should be
> optional, as I stated on GitHub:
> https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938
>
> I'm content to add the (optional) semicolon to #392.
>
> I don't know about the practical ramifications. Vlad may be best
> positioned to answer that.
>
> Richard
>
> On Jul 23, 2021, at 3:53 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> Dear all,
> Richard has now updated the proposal, but only Arnaud has commented on it.
> I think this requires a few more eyes, since it will permeate the language
> once people start using linear types, and we are already thinking about
> introducing modifiers in other parts.
>
> In fact, I’ve realised that there’s a (grammar) conflict between this
> proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 (the
> fine-grained pragmas for type classes and instances). This proposal defines
>
> topdecl ::= {modifier} 'type' simpletype '=' type
> | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving]
> | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving]
> | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls]
> | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls]
>
> But #390 defines (note the ; at the end of the modifiers block):
>
> modifiers : {- empty -} | ('%' qtycon)* ';'
> cl_decl : modifiers 'class' tycl_hdr fds where_cls
>
> I guess we should sort this out before accepting any of them.
>
> Alejandro
>
> El 28 jun 2021 21:26:45, Alejandro Serrano Mena <trupill at gmail.com>
> escribió:
>
>> Richard, will you take care of making those small changes to the
>> proposal? That way we could mark this as accepted.
>>
>> Regards,
>> Alejandro
>>
>> El 28 jun 2021 9:01:28, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> escribió:
>>
>>> Yes, I believe that Richard and I are in agreement now. I don't think
>>> all the conclusions have been added to the proposal yet, though; but
>>> whatever's left, it's fairly minor.
>>>
>>> On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena <
>>> trupill at gmail.com> wrote:
>>>
>>>> Dear all,
>>>> This discussion has been dormant for some time, but it’s time to revive
>>>> it!
>>>>
>>>> Richard, Arnaud, did you manage to reach conclusion about the
>>>> modification to the proposal?
>>>>
>>>> Apart from that, is there any other concern about the proposal? As I
>>>> said in my original message, this is a very small amendment to an
>>>> already-existing proposal, so if we accepted the previous one I see no
>>>> problem in this one. I’ll wait until Richard and Arnaud get back on the
>>>> issue, and then assume that silence for a week is acceptance.
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>> El 11 jun 2021 14:55:41, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>> escribió:
>>>>
>>>>> I think that my discussion with Richard has come to a conclusion (it
>>>>> should incur a small modification to the proposal).
>>>>>
>>>>> It is a very small (amendment to a) proposal, let's find a consensus
>>>>> on this one quickly.
>>>>>
>>>>>
>>>>> On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud <
>>>>> arnaud.spiwack at tweag.io> wrote:
>>>>>
>>>>>> I've commented on the PR [
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189
>>>>>> ] the changes on the syntax of lambda expressions are not motivated at all,
>>>>>> I think at the very least there should be a discussion in the Alternatives
>>>>>> section.
>>>>>>
>>>>>> But mostly, I'm worried about the implications/interactions that
>>>>>> these changes have with linear types.
>>>>>>
>>>>>> (I'll be off for the rest of the week starting tonight, so I'll be
>>>>>> back on this conversation on Monday, most likely)
>>>>>>
>>>>>> On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena <
>>>>>> trupill at gmail.com> wrote:
>>>>>>
>>>>>>> Dear Committee,
>>>>>>> This proposal seems a natural extension of #370, covering some
>>>>>>> additional cases (modifiers to classes and other declarations) that we’ve
>>>>>>> found along the way. My recommendation is acceptance.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alejandro
>>>>>>>
>>>>>>> On 4 May 2021 at 09:41:56, Joachim Breitner <
>>>>>>> mail at joachim-breitner.de> wrote:
>>>>>>>
>>>>>>>> Dear Committe,
>>>>>>>>
>>>>>>>> Clarify modifiers design principle
>>>>>>>> has been proposed by Richard
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392
>>>>>>>>
>>>>>>>> This is an amendmend to #370, see the PR description for links to
>>>>>>>> diffs
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> I propose Alejandro as the shepherd, as he shepherded #370 before.
>>>>>>>>
>>>>>>>> Please guide us to a conclusion as outlined in
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joachim
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Joachim Breitner
>>>>>>>>  mail at joachim-breitner.de
>>>>>>>>  http://www.joachim-breitner.de/
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ghc-steering-committee mailing list
>>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>>
>>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ghc-steering-committee mailing list
>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>
>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>
>>>>>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211223/71ec43b7/attachment.html>