<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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.<br>
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.<br>
<br>Hope that helps!<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"> - Clark<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 28, 2013 at 2:53 AM, Alejandro Serrano Mena <span dir="ltr"><<a href="mailto:trupill@gmail.com" target="_blank">trupill@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>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 :)</div>
<div><br></div><div>By the way, I'm also interested in knowing if extensible-effects have some relation to MonadPlus or Applicative in any way.</div><div><br></div><div>Thanks again for the answers! I really liked the ideas!</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/28 <span dir="ltr"><<a href="mailto:oleg@okmij.org" target="_blank">oleg@okmij.org</a>></span><div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> The extensible-effects package seems very interesting. I would really like<br>
> to have instances of all usual monads: Reader, Writer, State.Lazy and so on<br>
> in the package. Maybe that's a project for the future :)<br>
<br>
</div>There is already a Reader and Writer, in Control.Eff.State. I guess<br>
Ben Foppa collected them there because they all deal with aspects of<br>
State (unlike say, non-determinism or coroutine).<br>
<br>
I must stress that thinking of extensible-effects effects as just<br>
another implementation of MTL is not productive. Not all effects can<br>
be decomposed into State, Reader, etc. layers. Manly, effects should<br>
not be decomposed into layers.<br>
<br>
The recently discussed Logger was an excellent example. The original<br>
poster wondered if Logger is a Writer, or a Reader + IO, or something<br>
else. I'd suggest that the answer is that a Logger does a logging<br>
effect. One may then think what sort of interaction with the external<br>
world executing this logging effect should cause. The original poster<br>
thought exactly in these terms and outlined three scenarios. With<br>
extensible effects, one implements these scenarios directly.<br>
<br>
It seems MTL wrought quite a round-about way of thinking about<br>
effects. First we specify the desired interactions with the world and<br>
then we start thinking of decomposing them into `usual monads'. Why<br>
not to implement the specification directly, without any<br>
decomposition?<br>
<br>
To make an analogy, it is believed that a mathematical proof can be<br>
traced back to ZFC axioms. Yet no mathematician (unless working<br>
specifically on foundations) actually thinks of ZFC when doing the<br>
proof. [The analogy is imperfect: there are effects that cannot<br>
in principle be represented as composition of monad transformer<br>
layers.]<br>
<br>
<br>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Clark.<br><br><span style="font-family:courier new,monospace"><span style="color:rgb(153,153,153)"><font size="1">Key ID : 0x78099922<br>Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907</font></span></span></div>
</div>