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

[Arnaud Spiwack]

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.

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.

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?

On Mon, 2 Oct 2023 at 10:07, Adam Gundry <adam at well-typed.com> wrote:

> I'm unconvinced by the current state of this proposal, for similar
> reasons as Simon PJ gives on the proposal thread
> (
> https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610
> ).
>
> If we want to accept this merely for reasons of consistency, I think the
> simplest way forward would be to not introduce a new extension name, and
> instead define the combination of MonadComprehensions + ApplicativeDo to
> do what the proposal suggests.
>
> The author doesn't seem to be responsive on the thread. While I worry
> this may be because of the time the proposal process has been taking, it
> makes it difficult to gauge support for the various alternative
> suggestions that have been made.
>
> Cheers,
>
> Adam
>
>
> On 28/09/2023 08: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
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231002/6631cf6c/attachment.html>