<div dir="ltr"><div>The proposal looks a little half-baked in its current state. It'd need a little bit of clean-up before being accepted in my opinion. The point raised by Simon PJ about unclear desugaring is one. How guards are handled, since guards are primitive in the comprehension syntax. I don't think there's a technical challenge there, though.</div><div><br></div><div>I do appreciate the point in the proposal that for applicatives which aren't monad, the comprehension syntax is actually better suited than the “do” notation. I learned something in what would have otherwise been a rather dull day.</div><div><br></div><div>That being said, I think it's worth bringing up the question of the status of MonadComprehension. As far as I can tell, this is an extension that hasn't seen much love. Is MonadComprehension something that we're confident we want to build on? Maybe the implementation/maintenance effort for this proposal is low enough that the answer doesn't matter much?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 2 Oct 2023 at 10:07, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</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 unconvinced by the current state of this proposal, for similar <br>
reasons as Simon PJ gives on the proposal thread <br>
(<a href="https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610</a>).<br>
<br>
If we want to accept this merely for reasons of consistency, I think the <br>
simplest way forward would be to not introduce a new extension name, and <br>
instead define the combination of MonadComprehensions + ApplicativeDo to <br>
do what the proposal suggests.<br>
<br>
The author doesn't seem to be responsive on the thread. While I worry <br>
this may be because of the time the proposal process has been taking, it <br>
makes it difficult to gauge support for the various alternative <br>
suggestions that have been made.<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
On 28/09/2023 08: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>
> <br>
>   * Github thread <<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>
> <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>
> <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<br>
>     up during the discussion)<br>
>   * A future proposal can add a simpler version of the desugaring for<br>
>     both extensions later.<br>
> <br>
> <br>
> Cheers<br>
> Simon<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>