<div dir="ltr"><div>Working with stacks like "ReaderT AppConfig (StateT AppState IO)" may be hard, but using MonadIO, MonadState, MonadReader etc. is much simpler.</div><div><br></div><div>This session explains it well: <a href="https://www.youtube.com/watch?v=GZPup5Iuaqw">https://www.youtube.com/watch?v=GZPup5Iuaqw</a></div><div><br></div><div>I haven't yet tried Oleg's approach with Freer monads and extensible effects though, it looks very interesting. Especially when creating new types of effects because writing an "interpreter" seems easier than writing something like "MyEffectT / MyEffectMonad" and giving it all the required instances.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 19, 2016 at 11:57 PM David McBride <<a href="mailto:toad3k@gmail.com">toad3k@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">I'll say that this conversation caused me to rewrite some networking code I had written in a free monad as mtl.  It is faster and simpler, right?  But transformer stacks with all their typeclasses are really hard to work with and I don't think it was worth it in the end.<br class="gmail_msg"></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Wed, Oct 19, 2016 at 8:29 AM, Damian Nadales <span dir="ltr" class="gmail_msg"><<a href="mailto:damian.nadales@gmail.com" class="gmail_msg" target="_blank">damian.nadales@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was thinking, besides the evaluation of performance, the simplicity<br class="gmail_msg">
of the approach is also important ("developer time is more expensive<br class="gmail_msg">
than CPU time" anyone?). Note that I said simple and not easy ;)<br class="gmail_msg">
<br class="gmail_msg">
I guess this aspect is a rather subjective one, but maybe there are<br class="gmail_msg">
elements that can be intuitively quantified. Right now I'm playing<br class="gmail_msg">
with free monads and MTL, to have an idea which one seems simpler to<br class="gmail_msg">
me.<br class="gmail_msg">
<div class="m_700184442231914388HOEnZb gmail_msg"><div class="m_700184442231914388h5 gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Mon, Oct 17, 2016 at 8:06 PM, Julian <<a href="mailto:hasufell@hasufell.de" class="gmail_msg" target="_blank">hasufell@hasufell.de</a>> wrote:<br class="gmail_msg">
> On 15/10/16 15:49, Joachim Breitner wrote:<br class="gmail_msg">
>> Hi,<br class="gmail_msg">
>><br class="gmail_msg">
>> Am Freitag, den 14.10.2016, 17:35 +0200 schrieb Damian Nadales:<br class="gmail_msg">
>>> Do you have<br class="gmail_msg">
>>> any experience using any of these approaches. If so would you mind<br class="gmail_msg">
>>> sharing? ;)<br class="gmail_msg">
>><br class="gmail_msg">
>> I don’t have an answer to contribute, but I would be very interested in<br class="gmail_msg">
>> hearing about experiences in terms of their relative runtime<br class="gmail_msg">
>> performance.<br class="gmail_msg">
>><br class="gmail_msg">
>> My gut feeling is that an an indirect function call for every (>>=),<br class="gmail_msg">
>> with many calls to `lift` each time, would make a deep monad<br class="gmail_msg">
>> transformer stack much more expensive. A free monad approach seems to<br class="gmail_msg">
>> be more sensible to me. But maybe GHC is doing a better job optimizing<br class="gmail_msg">
>> this than I would think?<br class="gmail_msg">
>><br class="gmail_msg">
>> So if you have any number-supported evidence about this, possibly from<br class="gmail_msg">
>> a real-world application where you tried to use one or the other,<br class="gmail_msg">
>> please share it with us!<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> There's a paper from Oleg discussing "Freer Monads, More Extensible<br class="gmail_msg">
> Effects": <a href="http://okmij.org/ftp/Haskell/extensible/more.pdf" rel="noreferrer" class="gmail_msg" target="_blank">http://okmij.org/ftp/Haskell/extensible/more.pdf</a><br class="gmail_msg">
><br class="gmail_msg">
> The conclusion there seems to be that the EE approach is more<br class="gmail_msg">
> "efficient". But you'll have to look at the concrete performance cases<br class="gmail_msg">
> and data yourself to make a judgement.<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> Haskell-Cafe mailing list<br class="gmail_msg">
> To (un)subscribe, modify options or view archives go to:<br class="gmail_msg">
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="gmail_msg">
> Only members subscribed via the mailman list are allowed to post.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Haskell-Cafe mailing list<br class="gmail_msg">
To (un)subscribe, modify options or view archives go to:<br class="gmail_msg">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="gmail_msg">
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
Haskell-Cafe mailing list<br class="gmail_msg">
To (un)subscribe, modify options or view archives go to:<br class="gmail_msg">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="gmail_msg">
Only members subscribed via the mailman list are allowed to post.</blockquote></div>