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

[Eric Seidel]

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