-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MonadZero and MonadPlus #5
Conversation
I'm not too well versed on the whole Either way, I'm for this. |
I don't think it's supposed to be a superclass as there are cases that can't satisfy both left catch and left distribution. I'm not super well versed in the discussion either, just going off this for the most part. @jdegoes or @puffnfresh have any thoughts on this? |
@garyb I think I also recommend reading this awesome blog post: |
👍 🚢 Maybe we should move Also, then we can add a few more primitives like Are there any standard things like that for |
Also 👍 for breaking up |
I think we have |
I think we'd have to, yes. |
Is this OK to merge in its current state then, given that neither of these classes are affected by changes needed for I don't think there are any functions like |
Yes I think so. |
Do we plan to include any instances? |
I was thinking about that, I think instances should go in the modules that define the types that are suitable. At the moment As far as I know, the only instances we need for standard types are for
|
More related discussion at #6 |
I don't know if we want to lay down a consistent set of laws for MonadPlus, but left distribution seems to make sense to me over left catch, given that an
Alternative
instance can be used for left catch instead (I think?).MonadZero
as a separate class seems useful too, as we don't havefail
in ourMonad
, and also it matches how we do things withArrowZero
andArrowPlus
.