Deprecate MonadZero

[hdgarrood]

I proposed MonadZero originally, so it feels somehow appropriate that I’m going to be the one to argue for its demise.

Anyway, as noted in #51, the MonadZero annihilation law empty >>= f = empty is automatically satisfied for any law-abiding monad, due to parametricity: while evaluating empty >>= f, the function f can’t ever be called, since that would require empty to produce a value, which means that empty >>= f must be the same as empty >>= pure, which by the monad laws is just empty.

As far as I’m aware, the only place we’re using MonadZero is in the definition of guard. However, I’d argue that the Alternative annihilation law empty <*> f = empty already gives us enough to ensure that guard behaves sensibly. Haskell seems to agree, with its guard only requiring Alternative.

(Note: The Alternative annihilation law isn’t redundant: for a type which isn’t a monad, the effects of the second argument of <*> could be performed before the first).

Therefore, I propose we do the following:

• Add a deprecation notice to the MonadZero class
• Change guard to only require Alternative
• Change MonadPlus to have Monad and Alternative superclasses instead of MonadZero
• In a subsequent breaking release, remove MonadZero.

[JordanMartinez]

Sounds reasonable.

[hdgarrood]

I think I might post about this on Discourse, since this feels like a big enough change that we ought to solicit feedback on it.

[JordanMartinez]

Based on the discussion in the Discourse post, what changes need to be made here to close this issue?

Seems like

• change the definition of MonadZero to class (Alternative m, Monad m) => MonadZero m
• deprecate the class via docs

[hdgarrood]

That, plus changing the definition of MonadPlus to have Alternative and Monad superclasses. However I'd like to see if we can get closer to a consensus on #63 first, since I think the result of that discussion might have consequences for the MonadZero class.

[hdgarrood]

On reflection, I think whatever we do on #63, it's unlikely to have direct consequences for this issue. In particular, nobody seems to be defending MonadZero or proposing an alternative hierarchy which does include it. So I think we can go ahead and do this (and mark this library as 0.14-ready in the checklist on that compiler issue).

[thomashoneyman]

As mentioned in #177, should other libraries in core which use MonadZero (at least lists and maybe, and perhaps others) continue to do so, or should the instance be removed? The question is pertinent for at least CI, which will not pass as implemented now if there are any library warnings.

[JordanMartinez]

One way to get around the CI issue is to censor the UserDefinedWarnings because we're using a custom compiler warning.

spago build -u "--strict --censor-codes=UserDefinedWarning"

We'll want to censor it in some situations (e.g. updating repos) but not others (updating the package set).

[hdgarrood]

I think deprecating the class but removing the existing instances doesn’t make a whole lot of sense, because I’d guess most usages of the class probably rely on at least one of the instances in core; if we were going to remove the instances we might as well just remove the whole class. So for me it’s between skipping a deprecation cycle and just removing the whole class now, or removing the warning so that existing instances can compile without warnings. I’m leaning towards the latter.

I think the policy of “all libraries should always compile without warnings” is often incompatible with backwards compatibility and deprecation cycles - if you look at the warnings produced by Haskell dependencies I think the majority are to do with ongoing deprecation cycles - so perhaps in the longer term we might want to try to find a better compromise, perhaps allowing certain warnings but not others.