MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins [...]

...

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 64

[...]

On the libraries I maintain and have a copy of on my computer right now: 329

Although this was already pointed out to you in a response to a Tweet of yours, I'd like to expand on this here to clarify: You say that you stick to the 3-major-ghc-release support-window convention for your libraries. This is good, because then you don't need any CPP at all! Here's why: So when GHC 8.2 is released, your support-window requires you to support GHC 7.10 and GHC 8.0 in addition to GHC 8.2. At this point you'll be happy that you can start dropping those #ifdefs you added for GHC 7.10 in your code in order to adapt to FTP & AMP. And when you do *that*, you can also drop all your `return = pure` methods overrides. (Because we prepared for MRP already in GHC 7.10 by introducing the default implementation for `return`!) This way, you don't need to introduce any CPP whatsoever due to MRP! Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC 8.2 was just the *earliest theoretical* possible GHC in which this *could* have happened. Realistically, this would happen at a much later point, say GHC 8.6 or even later! Therefore, the scheme above would actually work for 5-year time-windows! And there's even an idea on the table to have a lawful `return = pure` method override be tolerated by GHC even when `return` has already moved out of `Monad`! PS: I'm a bit disappointed you seem to dismiss this proposal right away categorically without giving us a chance to address your concerns. The proposal is not a rigid all-or-nothing thing that can't be tweaked and revised. That's why we're having these proposal-discussions in the first place (rather than doing blind +1/-1 polls), so we can hear everyone out and try to maximise the agreement (even if we will never reach 100% consensus on any proposal). So please, keep on discussing!