Implement initial BindLeft and MonadLeft

[JordanMartinez]

Fixes #12

WIP

Things to do:

• Implement qualified do for ldiscard, lbind, lmap, and lapply

[JordanMartinez]

Should the convention be Flip.do rather than MonadLeft.do?

[kl0tl]

MonadLeft.do seems more meaningful to me than Flip.do, but writing MonadLeft.ado for a type with only an ApplicativeLeft instance and no MonadLeft is odd.

[JordanMartinez]

I read MonadLeft.do / MonadLeft.ado less of a "hey, this thing is a monad!" and more of a "hey, we're using the MonadLeft type class hierarchy here." That's how I read Ix.do, React.do, and Hooks.do.

[JordanMartinez]

What advantage would there be for defining an instance of MonadLeft and its superclasses instances for Flip if we have qualified do?

[kl0tl]

While lapply, lpure, lbind and ldiscard are consistent with lmap, llift* is awkward and lifM reads like a typo. This is consistent with the prefixes from bifunctors and indexed-monad though, so perhaps this ship has already sailed.

[kl0tl]

MonadLeft.do seems more meaningful to me than Flip.do, but writing MonadLeft.ado for a type with only an ApplicativeLeft instance and no MonadLeft is odd.

[JordanMartinez]

This is consistent with the prefixes from bifunctors and indexed-monad though, so perhaps this ship has already sailed.

We could always break convention here now and update bifunctors and indexed-monad to use a *Left suffix in a future breaking changes release. In this case, I'd rather have something readable than something short.

[JordanMartinez]

CI now builds.

[JordanMartinez]

The only thing blocking this PR is deciding on the naming convention for referencing this qualified do. I think BiLeft should be used as it's short for bifunctor and the left parameter used in the bifunctor.

[JordanMartinez]

I moved all the modules implemented here into a Control.Bifunctor module. This is so we reduce possible breaking changes if we ever want to implement a MonadLeft-like type class hierarchy for trifunctors.

I've also updated the naming convention for the qualified do to use BiLeft which distinguishes it from the Left constructor of Either and ties it to the underlying bifunctor type's left type parameter.

Can I get an approval on this?

[hdgarrood]

This is so we reduce possible breaking changes if we ever want to implement a MonadLeft-like type class hierarchy for trifunctors.

This feels like a case of YAGNI to me. It's hard for me to see us ever wanting to do that in core; even this version of MonadLeft has only generated minimal interest.

[JordanMartinez]

It's hard for me to see us ever wanting to do that in core; even this version of MonadLeft has only generated minimal interest.

How about I publish this as a separate library then?

[hdgarrood]

I don't have a strong view on whether MonadLeft should be in core or not, but I think the argument that it should be here so that we can provide Monad Flip makes sense to me. It's just that I think it probably is safe to say that a version of MonadLeft which works on the first of three type variables is not useful often enough to deserve to be in core, and therefore I'd suggest not designing this library in such a way as to make space to do that in the future.

[JordanMartinez]

Ah... That does make sense.

[JordanMartinez]

Closing as this hasn't received an approval or further feedback.