<div dir="ltr"><div>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.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 30 Sept 2023 at 18:57, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
On Thu, Sep 28, 2023, at 03:12, Simon Marlow wrote:<br>
> Dear committee,<br>
><br>
> #526 proposes a new extension ApplicativeComprehensions (implying <br>
> MonadComprehensions). It would provide the equivalent of the current <br>
> ApplicativeDo desugaring for do-expressions to list comprehensions.<br>
>  • Github thread <br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/526" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/526</a>><br>
>  • Rendered <br>
> <<a href="https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst" rel="noreferrer" target="_blank">https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst</a>><br>
> The extension itself is relatively uncontroversial, but there are some <br>
> unresolved quirks in the original ApplicativeDo extension which made us <br>
> uneasy about extending it. However, after various discussions I'm going <br>
> to propose accepting this proposal in its current state.  Rationale:<br>
>  • It doesn't make things worse, and the implementation isn't likely to <br>
> add significant complexity.<br>
>  • It retains consistency between ApplicativeDo and <br>
> ApplicativeComprehensions (in contrast to the idea of making <br>
> ApplicativeComprehensions perform a simpler desugaring, which came up <br>
> during the discussion)<br>
>  • A future proposal can add a simpler version of the desugaring for <br>
> both extensions later.<br>
><br>
> Cheers<br>
> Simon<br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>