I'm not too well versed on the whole MonadPlus, MonadZero, MonadOr deal, but isn't Alternative supposed to be a superclass for one of these?

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 Alternative would be a super-class for MonadOr, which is left out of this.

I also recommend reading this awesome blog post:

http://winterkoninkje.dreamwidth.org/90905.html

👍 🚢

Maybe we should move Alternative into control as well. I don't think it's used in Prelude.

Also, then we can add a few more primitives like some and many in a new Control.Alternative module.

Are there any standard things like that for MonadZero or MonadPlus?

Also 👍 for breaking up Alternative if it can be done easily.

I think we have Alternative instances defined in a few of the other core libraries so I guess we'd move those in here too then?

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 MonadOr or Alternative?

I don't think there are any functions like some or many to go along with MonadPlus, aside from guard, which I've just added. There's also msum, but that should probably go with Foldable.

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 purescript-control has no dependencies, so it would seem sensible to keep it that way and have things depend on it.

As far as I know, the only instances we need for standard types are for Array and Maybe, and perhaps something like Error e <= Either e.

Array and Maybe are also Alternative, so adding the dependency to purescript-control on the data side would make sense for that too.

More related discussion at #6