Reader/Writer/State are handled in extensible-effects inside
Control.Eff.State. Cont is handled in Control.Eff.Coroutine (although could
use better documentation, patches welcome!). RWS isn't done, but I don't
see why it can't be implemented in terms of State! Error is provided by
Control.Eff.Exception, and a substitute for monad-supply is provided by
Control.Eff.Fresh. Random numbers are in a new package:
system-random-effect.
Eff is an instance of applicative, but not MonadPlus. I don't immediately
see a way to make it an instance of MonadPlus, especially since we can have
an 'IO' effect.
Hope that helps!
- Clark
On Thu, Nov 28, 2013 at 2:53 AM, Alejandro Serrano Mena
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
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
-- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907