Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/proposa... I propose Eric Seidel as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi all, My wife and I just checked into the hospital to have our second child, 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. I reviewed the proposal over the weekend and left some thoughts on GitHub. I’m supportive of the direction — partial patterns in do-notation are more consistent with the rest of the language — but I thought it would be a stronger proposal if we had a syntax for controlling the failure behavior. This would give people who currently rely on the MonadFail desugaring a cleaner migration path. John has another proposal (#327 iirc) exploring how that syntax might look, I suggested building on top of that proposal or combining the two. Eric Sent from my iPhone
On May 1, 2020, at 04:04, Joachim Breitner
wrote: Dear Committee,
this is your secretary speaking:
NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/proposa...
I propose Eric Seidel as the shepherd.
Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process
Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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

Dear Committee, I would like to kindly ask for your input in the NoFallibleDo proposal -> https://github.com/ghc-proposals/ghc-proposals/pull/319 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@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@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@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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
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@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf1d337b38f29446b0aed08d832cf6866%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315213676738835&sdata=tH6FlYs7ZbnHLLZ4Pz5VvKsrO84KK%2B5Tw8Cn0oFqjj8%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf1d337b38f29446b0aed08d832cf6866%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315213676738835&sdata=%2BhlFzY%2F1CcP8tE2sdZJnXilMqsZtZWlIB%2Ftp00agv5Q%3D&reserved=0

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@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
*On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner *Cc:* ghc-steering-committee *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%7Cf1d337b38f29446b0aed08d832cf6866%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315213676728880&sdata=yFv7PtIaMxIv7FBTXkhJboLZ4i54g%2B6YuyPEC1Xg6ZA%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@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@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@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%7Cf1d337b38f29446b0aed08d832cf6866%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315213676738835&sdata=tH6FlYs7ZbnHLLZ4Pz5VvKsrO84KK%2B5Tw8Cn0oFqjj8%3D&reserved=0
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf1d337b38f29446b0aed08d832cf6866%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315213676738835&sdata=%2BhlFzY%2F1CcP8tE2sdZJnXilMqsZtZWlIB%2Ftp00agv5Q%3D&reserved=0

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
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@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C5b2c08cee5734215cbe708d832d7a993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315249124598638&sdata=YI3cPGedd1adfgequqeNtWJwUupFzkpWp6FfGKj1FZ8%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C5b2c08cee5734215cbe708d832d7a993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315249124598638&sdata=9BGzF3bs%2FVir0CqcGb101VxOFh%2FhlXMr1KID6GZJELE%3D&reserved=0

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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner *Cc:* ghc-steering-committee *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%7C5b2c08cee5734215cbe708d832d7a993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315249124588682&sdata=2l1wYxmnm3qB77ePDiZzvuKI8UQABr9JNy0l8lygGPE%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@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@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@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%7C5b2c08cee5734215cbe708d832d7a993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315249124598638&sdata=YI3cPGedd1adfgequqeNtWJwUupFzkpWp6FfGKj1FZ8%3D&reserved=0
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C5b2c08cee5734215cbe708d832d7a993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315249124598638&sdata=9BGzF3bs%2FVir0CqcGb101VxOFh%2FhlXMr1KID6GZJELE%3D&reserved=0

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
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@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0

Done. Once again, sorry for the confusion. Alejandro El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner *Cc:* ghc-steering-committee *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@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@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@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@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

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-8855800...
(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
Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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

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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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

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
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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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"
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
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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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
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"
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@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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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
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"
mailto:arnaud.spiwack@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
mailto:trupill@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
mailto:trupill@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-8855800... https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-8855800... (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
mailto:trupill@gmail.com> escribió: Done. Once again, sorry for the confusion. Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (
mailto:simonpj@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
mailto:trupill@gmail.com> Sent: 28 July 2020 10:25 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 (
mailto:simonpj@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
mailto:trupill@gmail.com> Sent: 28 July 2020 10:22 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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 (
mailto:simonpj@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
mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Alejandro Serrano Mena Sent: 28 July 2020 09:22 To: Joachim Breitner mailto:mail@joachim-breitner.de> Cc: ghc-steering-committee mailto:ghc-steering-committee@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 (
mailto:trupill@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 (
mailto:mail@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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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
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
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"
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@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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
*Sent:* 28 July 2020 10:25 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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
*Sent:* 28 July 2020 10:22 *To:* Simon Peyton Jones *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 28 July 2020 09:22 *To:* Joachim Breitner
*Cc:* ghc-steering-committee *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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

As I see no message on this matter, I’ll go on with the chosen outcome, and
notify the authors about it.
Regards,
Alejandro
El 23 dic 2021 13:51:40, Alejandro Serrano Mena
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
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
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"
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@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
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-8855800... (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
escribió: Done. Once again, sorry for the confusion.
Alejandro
El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< simonpj@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
> *Sent:* 28 July 2020 10:25 > *To:* Simon Peyton Jones > *Cc:* ghc-steering-committee@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@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 > *Sent:* 28 July 2020 10:22 > *To:* Simon Peyton Jones > *Cc:* ghc-steering-committee@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@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@haskell.org> *On Behalf Of *Alejandro > Serrano Mena > *Sent:* 28 July 2020 09:22 > *To:* Joachim Breitner > *Cc:* ghc-steering-committee > *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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
participants (6)
-
Alejandro Serrano Mena
-
Eric Seidel
-
Joachim Breitner
-
Richard Eisenberg
-
Simon Peyton Jones
-
Spiwack, Arnaud