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

[Simon Peyton Jones]

I too am concerned that the author @strake has not responded since Oct
2022.   Nor have we seen a chorus of support from other users.

My suggestion

   - Park the proposal for now
   - Reach out to the author to check that they are OK

Simon M: you are shepherding; what do you think?

Simon

On Mon, 2 Oct 2023 at 09: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231003/028c99c0/attachment.html>