[ghc-steering-committee] #380 GHC2021: MonadFailDesugaring
Simon Peyton Jones
simonpj at microsoft.com
Mon Dec 28 09:52:05 UTC 2020
The user manual is pretty confusing.
* The extension is enabled by default
* The extension is temporary and will be deprecated in future
Those two seem to contradict.
Let's check. I believe that,
* Today, by default, MonadFailDesugaring is on;
that is, we desugar do-blocks to use MonadFail.fail
* That behaviour is what we want, permanently
* The extension -XMonadFailDesugaring and -XNoMonadFailDesugaring
are already deprecated, but have not yet been removed.
* When we remove them, we'll continue to desugar do-blocks to us
We were due to remove them in 8.8, as the proposal says under "Transitional Strategy"
But we failed to do so.
I conclude: we don't need votes on this. We should just execute on the proposal and remove the flags.
I see that the proposal lists the following steps for GHC 8.2:
1. Remove -XMonadFail leaving its effects on at all times.
2. Remove fail from Monad
3. Instead, re-export Control.Monad.Fail.fail as Prelude.fail
4. Control.Monad.Fail is now a redundant module that can be
We appear to have done (2) and (3), but not (1) or (4). Would someone like to make a ticket to do them?
| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 December 2020 14:26
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] #380 GHC2021:
| mostly a technical point, but just to avoid confusion
| MonadFailDesugaring is already on by default, and according to the
| docs, is supposed to be deprecated, _but making that behaviour
| permanent_. (So, really, NoMonadFailDesugaring is what is being
| I was previously confused by this and voted for "no", which is not
| what my intention is. I updated my vote to "yes".
| This now has 7 votes and reached "barely out" status.
| Dear Richard and Simon, Simon, Tom:
| You currently have "maybe", "irrelevant" or "no" here. Do you indeed
| want to deviate from the documented plan of getting rid of
| Joachim Breitner
| mail at joachim-breitner.de
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
More information about the ghc-steering-committee