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

Simon Marlow marlowsd at gmail.com
Sat Sep 30 18:31:45 UTC 2023


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230930/87a19182/attachment.html>


More information about the ghc-steering-committee mailing list