[Haskell-cafe] MTL vs Free-monads, what are your experiences

[David McBride]

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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161019/0ae07a8e/attachment.html>