[ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default

[Tom Harding]

Hi Arnaud,

My understanding is we’re past phase 1, en route to phase 2, and may be here for quite a while. For reference, phase 1:

Implement new warning in GHC which gets triggered when Monad instances explicitly override the default return and (>>) method implementations with non-lawful definitions (see compatible instance definition example in previous section).

The warning was implemented in GHC 8.0 and is called -Wnoncanonical-monad-instances (there are variants of this warning flag for Monoid and Fail) but it is not included in either -Wall or -Wcompat.

With that completed, phase 2 will be:

When we're confident that the majority of Hackage has reacted to the warning (with the help of Stackage actively purs
uing maintainers to update their packages) we turn the return and (>>) methods into a top-level binding and let GHC ignore lawful method definitions of return and (>>).

https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return

As Ben was the last to edit the page (albeit a year ago), perhaps he has some further insight?
I’ve CC’d him, just in case.

Thanks,
Tom

On 1 Apr 2020, at 12:48, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:

Dear all,

Can someone enlighten me as to the current status of the Monad-of-no-return proposal? Which is the motivation for this proposal.

Best,
Arnaud

On Wed, Apr 1, 2020 at 12:50 AM Tom Harding <tomjharding at live.co.uk<mailto:tomjharding at live.co.uk>> wrote:
Friends,

This proposal seems very reasonable to me, and the ramifications are minimal. Consequently, I recommend that we accept.

I’d now like to open the proposal up to committee discussion. My belief is that the issue be fairly uncontentious (particularly as prior behaviour can be fully restored by explicitly passing the relevant `-Wno-...` flags to the compiler), but I welcome any thoughts either way.

Thanks,
Tom
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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/20200403/bf84b9d1/attachment.html>