Thanks for both the pointers and the discussion about extensible-effects. I had some time yesterday to look at the paper itself, and I found it really useful and clean.

Even though, I still think that porting more monad transformers into extensible-effects could help the latter being used more widely. Right now MTL provides Reader, Writer, State, Cont, Error, RWS; and we have packages for random numbers, or monad-supply for a supply of unique values. I would be willing to use extensible-effects if I knew that I can do all of that within the framework. I still see the possibility of having a nice weekend projects in Haskell :)

By the way, I'm also interested in knowing if extensible-effects have some relation to MonadPlus or Applicative in any way.

Thanks again for the answers! I really liked the ideas!

2013/11/28 <oleg@okmij.org>

> The extensible-effects package seems very interesting. I would really like
> to have instances of all usual monads: Reader, Writer, State.Lazy and so on
> in the package. Maybe that's a project for the future :)

There is already a Reader and Writer, in Control.Eff.State. I guess
Ben Foppa collected them there because they all deal with aspects of
State (unlike say, non-determinism or coroutine).

I must stress that thinking of extensible-effects effects as just
another implementation of MTL is not productive. Not all effects can
be decomposed into State, Reader, etc. layers. Manly, effects should
not be decomposed into layers.

The recently discussed Logger was an excellent example. The original
poster wondered if Logger is a Writer, or a Reader + IO, or something
else. I'd suggest that the answer is that a Logger does a logging
effect. One may then think what sort of interaction with the external
world executing this logging effect should cause. The original poster
thought exactly in these terms and outlined three scenarios. With
extensible effects, one implements these scenarios directly.

It seems MTL wrought quite a round-about way of thinking about
effects. First we specify the desired interactions with the world and
then we start thinking of decomposing them into `usual monads'. Why
not to implement the specification directly, without any
decomposition?

To make an analogy, it is believed that a mathematical proof can be
traced back to ZFC axioms. Yet no mathematician (unless working
specifically on foundations) actually thinks of ZFC when doing the
proof. [The analogy is imperfect: there are effects that cannot
in principle be represented as composition of monad transformer
layers.]

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe