Working with stacks like "ReaderT AppConfig (StateT AppState IO)" may be hard, but using MonadIO, MonadState, MonadReader etc. is much simpler.

This session explains it well: https://www.youtube.com/watch?v=GZPup5Iuaqw

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.


On Wed, Oct 19, 2016 at 11:57 PM David McBride <toad3k@gmail.com> wrote:
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.

On Wed, Oct 19, 2016 at 8:29 AM, Damian Nadales <damian.nadales@gmail.com> wrote:
I was thinking, besides the evaluation of performance, the simplicity
of the approach is also important ("developer time is more expensive
than CPU time" anyone?). Note that I said simple and not easy ;)

I guess this aspect is a rather subjective one, but maybe there are
elements that can be intuitively quantified. Right now I'm playing
with free monads and MTL, to have an idea which one seems simpler to
me.



On Mon, Oct 17, 2016 at 8:06 PM, Julian <hasufell@hasufell.de> wrote:
> On 15/10/16 15:49, Joachim Breitner wrote:
>> Hi,
>>
>> Am Freitag, den 14.10.2016, 17:35 +0200 schrieb Damian Nadales:
>>> Do you have
>>> any experience using any of these approaches. If so would you mind
>>> sharing? ;)
>>
>> I don’t have an answer to contribute, but I would be very interested in
>> hearing about experiences in terms of their relative runtime
>> performance.
>>
>> My gut feeling is that an an indirect function call for every (>>=),
>> with many calls to `lift` each time, would make a deep monad
>> transformer stack much more expensive. A free monad approach seems to
>> be more sensible to me. But maybe GHC is doing a better job optimizing
>> this than I would think?
>>
>> So if you have any number-supported evidence about this, possibly from
>> a real-world application where you tried to use one or the other,
>> please share it with us!
>>
>
> There's a paper from Oleg discussing "Freer Monads, More Extensible
> Effects": http://okmij.org/ftp/Haskell/extensible/more.pdf
>
> The conclusion there seems to be that the EE approach is more
> "efficient". But you'll have to look at the concrete performance cases
> and data yourself to make a judgement.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.