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