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

Fri Dec 17 17:00:05 UTC 2021

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

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

/Arnaud

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

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