As it appears to be only additional syntax with no breakage of existing programs, I'm supportive! On Sun, 1 Oct 2023 at 02:32, Simon Marlow wrote:

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.

Cheers Simon

On Sat, 30 Sept 2023 at 18:57, Eric Seidel wrote:

...

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-applicativ...

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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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-1740735... ).

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-applicativ...

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@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.

I've made it dormant and posted on the thread to ask the submitter if they're still interested in the proposal. On Tue, 3 Oct 2023 at 11:11, Simon Peyton Jones wrote:

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 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-1740735... ).

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-applicativ...

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee