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

[Moritz Angermann]

As it appears to be only additional syntax with no breakage of existing
programs, I'm supportive!

On Sun, 1 Oct 2023 at 02:32, Simon Marlow <marlowsd at gmail.com> wrote:

> We certainly wouldn't want to include either ApplicativeDo or
> ApplicativeComprehensions in GHC20xx, indeed it was never the intention
> that ApplicativeDo would be enabled by default. Perhaps the simpler
> predictable form (yet to be proposed) could be in a future GHC20xx.
>
> Cheers
> Simon
>
> On Sat, 30 Sept 2023 at 18:57, Eric Seidel <eric at seidel.io> wrote:
>
>> I'm on the fence about this one. I can see the utility, sure, but we've
>> also been talking a lot about stability of extensions lately. One question
>> I asked myself while reading the proposal is whether I would support
>> including this extension (or MonadComprehensions) in the next GHC20XX. I'm
>> not sure but my gut reaction is probably not.
>>
>> On Thu, Sep 28, 2023, at 03: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
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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/20231002/95888fa2/attachment.html>