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