[ghc-steering-committee] Please review #687: Monad of No Return

[Arnaud Spiwack]

I also agree that _if_ we do the changes that the proposal wants, then the
revised timeline/steps sound better than the original.

On Sat, 12 Apr 2025 at 05:39, Matthías Páll Gissurarson via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> I agree, we should wait for the CLC before voting on this proposal.
>
> To summarize:
>
> 10 years ago, the CLC voted on the "Monad of No Return" proposal, which
> removes `return` and `(>>)` from `Monad`, to be replaced by `pure` and
> `(*>)` from `Applicative`, with `return` and `(>>)` being replaced with
> top-level bindings. The implementation of this was to proceed in multiple
> phases:
> + Phase 1 (implemented in 8.2, default in 9.2) that warns when `return`
> and `(>>)` are overwritten with non-canonical implementations (something
> other than `pure` and `(*>)`)
> + Phase 2: `return` and `(>>)` become top-level bindings and GHC ignores
> canonical implementation of these
> + Phase 3: Warn about all `return` and `(>>)` overwrites
> + Phase 4: Disallow overwrites of `return` and `(>>)`, removing them from
> Monad.
>
> This proposal proposes merging these into 2 phases:
> + Phase 2: Make non-canonical implementations of `(>>)` and `return` a
> compilation error, and add a warning for canonical ones
> + Phase 3: Move `return` and `(>>)` to the top-level and remove them from
> Monad.
>
> I'm in favor of *this specific change*, i.e. reducing the phases and
> easing migration.
>
> However, there are multiple concerns raised with the original MoNR
> proposal, as compiled by Julian:
> + `(*>)` is not as performant as `(>>)` in some cases, which affects a
> large portion of the ecosystem, as this is an "unseen default".
> + The impact assessment is stale, and the original motivation outdated
> + There are some corner cases that mean that behavior might potentially
> change, which is worrying
>
> So there's a question of whether we should keep going with the "Monad of
> No Return" proposal at all (of which this proposal is a modification), and
> if so, in what form we should do so.
>
> As Simon points out, the CLC is discussing this, and I agree that the time
> is not right for a vote at the moment. We should think about the original
> proposal, and I encourage you to weigh in on the [CLC discussion](
> https://github.com/haskell/core-libraries-committee/issues/325) (it's
> "internal", but multiple observers have already chimed in)
>
> Unless anyone disagrees in the next 2 days (i.e. by Monday), I will inform
> the authors of this proposal of this, and suggest that we move the proposal
> back to "under revision" until we've gotten feedback from the CLC.
>
>
> On Fri, 11 Apr 2025 at 10:01, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Can I draw your attention to
>> https://github.com/haskell/core-libraries-committee/issues/325#issuecomment-2796062617
>> ?
>>
>> The CLC plan to revisit the proposal, and while continued discussion here
>> is fine, I don't think we could act until the CLC concludes.  My thought:
>> let's move this back to "under revision" rather than shepherd it to a
>> conclusion.
>>
>> We (maybe Adam or Matthias?) should write to the authors to explain
>> this.  In a sympathetic and supportive way -- I think we all want to see
>> Haskell progress towards beauty and not just keep bad warts; but it's just
>> a tricky one.
>>
>> Simon
>>
>> On Fri, 11 Apr 2025 at 08:50, Matthías Páll Gissurarson via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>>> Thank you all! This is a slightly nuanced one, so I’ll write a summary
>>> today for us to vote on.
>>>
>>> /Matti Palli
>>>
>>>
>>> On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee <
>>> ghc-steering-committee at haskell.org> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> Benjamin proposes to revive and move forward the Monad of No Return
>>>> proposal:
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/687
>>>>
>>>> https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst
>>>>
>>>> I'd like to nominate Matthías as the shepherd.
>>>>
>>>> Please guide us to a conclusion as outlined in
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>
>>>> Cheers,
>>>>
>>>> Adam
>>>>
>>>> --
>>>> 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
>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> --  Matthías Páll Gissurarson <http://mpg.is/>
> _______________________________________________
> 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/20250414/0f966201/attachment.html>