Add benchmarks to compare extensible-effects

[fosskers]

I've been on the Eff bandwagon for a while now, and have really enjoyed using extensible-effects. The project's momentum seems low, and it doesn't yet include the improvements from the Freer paper (and might never). I noticed yesterday that freer had been forked, and since it looks like you have commercial backing, this library will probably stay the best maintained and have the most resources devoted to it. So I'm throwing in my chips with you (I use EE a lot).

This PR adds benchmarks for comparing extensible-effects alongside freer-effects and mtl. Suffice to say, FE does quite a bit better than EE.

As a tangent, I prefer your API surrounding lifting Monads into Eff. It took me a while to figure out that send was the mechanic to do that, but I like that it avoids the whole SetMember ceremony that extensible-effects chose. However I don't enjoy that runReader and runState have their state argument passed second. It's very annoying for application:

foo = run . runError $ runReader (runState (runWriter bar) s) env

as opposed to

foo = run . runError . runReader env . runState s $ runWriter bar

[trskop]

Thanks for doing this!

Regarding send, the documentation is still lacking a great deal, but we are hoping to gradually add examples from real-world use cases.

As for runReader, you are right that it's not very convenient. We are trying to keep backwards compatibility whenever reasonable. So, I'm not expecting its definition to change. However, we've already talked about adding a flipped variant for it, and other effect handlers as well.

Even though we are commercially backed, there is a certain priority to our work, and some of these conveniences may get pushed down to lower priorities, unless they are needed for our work. On the other hand, we'll try our best to be receptive to any pull requests.

There is also a supplementary package freer-extra, which will be released soon (under the name freer-effects-extra). Some of its code may slowly find its way into freer-effects. At the moment, it's more or less my personal project, therefore, adding experimental stuff may be faster.

[fosskers]

Right, I remember API compatibility with MTL being a goal of the original paper. I'd call the current order a historical mishap, then :P

Quirks aside, I'd say you guys are the Extensible Effects flagship, and I'm looking forward to what comes out of this.