[ghc-steering-committee] #526: Applicative Comprehensions (rec: accept)

[Simon Marlow]

I've made it dormant and posted on the thread to ask the submitter if
they're still interested in the proposal.

On Tue, 3 Oct 2023 at 11:11, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I too am concerned that the author @strake has not responded since Oct
> 2022.   Nor have we seen a chorus of support from other users.
>
> My suggestion
>
>    - Park the proposal for now
>    - Reach out to the author to check that they are OK
>
> Simon M: you are shepherding; what do you think?
>
> Simon
>
> On Mon, 2 Oct 2023 at 09:07, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm unconvinced by the current state of this proposal, for similar
>> reasons as Simon PJ gives on the proposal thread
>> (
>> https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610
>> ).
>>
>> If we want to accept this merely for reasons of consistency, I think the
>> simplest way forward would be to not introduce a new extension name, and
>> instead define the combination of MonadComprehensions + ApplicativeDo to
>> do what the proposal suggests.
>>
>> The author doesn't seem to be responsive on the thread. While I worry
>> this may be because of the time the proposal process has been taking, it
>> makes it difficult to gauge support for the various alternative
>> suggestions that have been made.
>>
>> Cheers,
>>
>> Adam
>>
>>
>> On 28/09/2023 08:12, Simon Marlow wrote:
>> > Dear committee,
>> >
>> > #526 proposes a new extension ApplicativeComprehensions (implying
>> > MonadComprehensions). It would provide the equivalent of the current
>> > ApplicativeDo desugaring for do-expressions to list comprehensions.
>> >
>> >   * Github thread <
>> https://github.com/ghc-proposals/ghc-proposals/pull/526>
>> >   * Rendered
>> >     <
>> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
>> >
>> >
>> > The extension itself is relatively uncontroversial, but there are some
>> > unresolved quirks in the original ApplicativeDo extension which made us
>> > uneasy about extending it. However, after various discussions I'm going
>> > to propose accepting this proposal in its current state.  Rationale:
>> >
>> >   * It doesn't make things worse, and the implementation isn't likely to
>> >     add significant complexity.
>> >   * It retains consistency between ApplicativeDo and
>> >     ApplicativeComprehensions (in contrast to the idea of making
>> >     ApplicativeComprehensions perform a simpler desugaring, which came
>> >     up during the discussion)
>> >   * A future proposal can add a simpler version of the desugaring for
>> >     both extensions later.
>> >
>> >
>> > Cheers
>> > Simon
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20231003/fdda5793/attachment-0001.html>