<div dir="auto">No, it doesn't hurt much right now. But if there Monad of no return proposal goes through, I think it will become pretty much unusable. I therefore think this proposal should be tied to that one.<div dir="auto"><br></div><div dir="auto">Separately, the instances don't seem ideal. In particular, I would have expected it to define<div dir="auto"><br></div><div dir="auto">x <$ WrapMonad m = WrapMonad (m >> return x)</div><div dir="auto">(*>) = (>>)</div><div dir="auto"><br></div><div dir="auto">but instead it lets both those methods take their default definitions. It also seems to be missing a MonadPlus instance.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 26, 2018, 2:28 AM Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Thu, 26 Apr 2018, David Feuer wrote:<br>
<br>
> Henning, how hard would it be to add some CPP to make those packages<br>
> work without WrappedMonad with base >= 4.8.0?<br>
<br>
I try to prevent CPP whereever possible. I would certainly add my own <br>
WrapMonad. But then, does WrapMonad in 'base' hurt?<br>
</blockquote></div>