[ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel

Fri Dec 17 16:55:58 UTC 2021

 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>