MTL vs Free-monads, what are your experiences

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

MTL vs Free-monads, what are your experiences

Damian Nadales
Hi,

I was looking into free monads for designing a DSL for describing
scenarios of the form:
  scenario = do
    aId <- createA
    b0Id <- createB id
    b1Id <- createB id
    link b0 b1

In our company we use a graph database, and currently we're setting up
the test data using raw queries O.O So I wanted to come up with a
better abstraction, and also enable us to do property based testing
(by testing on random scenarios like the one above).

Anyway, I ran into this presentation:
    http://www.slideshare.net/jdegoes/mtl-versus-free
    http://degoes.net/articles/modern-fp-part-2

In which monad transformers and free monads are compared. Do you have
any experience using any of these approaches. If so would you mind
sharing? ;)

Thanks!
Damian
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Matt
The mtl technique subsumes the free monad technique. if you have a term:

getCurrentTime :: MonadClock m => m UTCTime

Then you can *use* that function as anything that satisfies the constraint. Given an `IO` instance, that can just get the current time: `getCurrentTime :: IO UTCTime`. Given a mock instance, that can be `getCurrentTime :: MockClock UTCTime`. Given an instance on Free, you'd have `getCurrentTime :: Free CurrentTimeF UTCTime`

I generally find it more pleasant to write functions in mtl style. If you're after more concrete guarantees on the DSL you're building and see yourself doing a lot of introspection and optimization, then a Free monad approach fits the bill.

Matt Parsons

On Fri, Oct 14, 2016 at 11:35 AM, Damian Nadales <[hidden email]> wrote:
Hi,

I was looking into free monads for designing a DSL for describing
scenarios of the form:
  scenario = do
    aId <- createA
    b0Id <- createB id
    b1Id <- createB id
    link b0 b1

In our company we use a graph database, and currently we're setting up
the test data using raw queries O.O So I wanted to come up with a
better abstraction, and also enable us to do property based testing
(by testing on random scenarios like the one above).

Anyway, I ran into this presentation:
    http://www.slideshare.net/jdegoes/mtl-versus-free
    http://degoes.net/articles/modern-fp-part-2

In which monad transformers and free monads are compared. Do you have
any experience using any of these approaches. If so would you mind
sharing? ;)

Thanks!
Damian
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Joachim Breitner-2
In reply to this post by Damian Nadales
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!

Thanks,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
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.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Heinrich Apfelmus
> 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?

Well, my gut feeling would be that free monads are more expensive than a
monad transformer stack with <= 3 layers. After all, for
free/operational monads, the compiler has to allocate a closure for
every second argument of `>>=` as part of the monad data structure.
There are less opportunities for inlining, because the interpretation of
the monad is not fixed, and only decided late at runtime.

That said, the above arguments are no proof. I would be interested in
performance measurements as well.


Maybe there is a way to generalize the "GHC state hack" to a "free monad
hack"? The basic ansatz would be the ability to mark some closures as
"Only entered once, may duplicate work".


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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!
>
> Thanks,
> Joachim
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Generalized state hack (was: MTL vs Free-monads)

Joachim Breitner-2
Hi,

Am Sonntag, den 16.10.2016, 10:22 +0200 schrieb Heinrich Apfelmus:
> Maybe there is a way to generalize the "GHC state hack" to a "free monad 
> hack"? The basic ansatz would be the ability to mark some closures as 
> "Only entered once, may duplicate work".

recent related discussion (in the context of pipes):
https://ghc.haskell.org/trac/ghc/ticket/12620#comment:5

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
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.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Damian Nadales
In reply to this post by Matt
On Fri, Oct 14, 2016 at 6:00 PM, Matt <[hidden email]> wrote:

> The mtl technique subsumes the free monad technique. if you have a term:
>
> getCurrentTime :: MonadClock m => m UTCTime
>
> Then you can *use* that function as anything that satisfies the constraint.
> Given an `IO` instance, that can just get the current time: `getCurrentTime
> :: IO UTCTime`. Given a mock instance, that can be `getCurrentTime ::
> MockClock UTCTime`. Given an instance on Free, you'd have `getCurrentTime ::
> Free CurrentTimeF UTCTime`
>
Thanks Matt. I think that was a nice explanation. Right now I'm
focusing on the composition and natural transformations of
free-monads, but I still haven't checked the MTL approach.

> I generally find it more pleasant to write functions in mtl style. If you're
> after more concrete guarantees on the DSL you're building and see yourself
> doing a lot of introspection and optimization, then a Free monad approach
> fits the bill.
>
I definitely like monad transformers. But I guess I'd have to explain
the specific case in another thread.

> Matt Parsons
>
> On Fri, Oct 14, 2016 at 11:35 AM, Damian Nadales <[hidden email]>
> wrote:
>>
>> Hi,
>>
>> I was looking into free monads for designing a DSL for describing
>> scenarios of the form:
>>   scenario = do
>>     aId <- createA
>>     b0Id <- createB id
>>     b1Id <- createB id
>>     link b0 b1
>>
>> In our company we use a graph database, and currently we're setting up
>> the test data using raw queries O.O So I wanted to come up with a
>> better abstraction, and also enable us to do property based testing
>> (by testing on random scenarios like the one above).
>>
>> Anyway, I ran into this presentation:
>>     http://www.slideshare.net/jdegoes/mtl-versus-free
>>     http://degoes.net/articles/modern-fp-part-2
>>
>> In which monad transformers and free monads are compared. Do you have
>> any experience using any of these approaches. If so would you mind
>> sharing? ;)
>>
>> Thanks!
>> Damian
>> _______________________________________________
>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Alberto G. Corona
In reply to this post by Joachim Breitner-2
There is a free monad benchmark: 


Not very good for the free monads. But it is done only with a single transformer and for a single state. I don´t know how the MTL performance degrades when the transformer stack grows.

2016-10-15 15:49 GMT+02:00 Joachim Breitner <[hidden email]>:
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!

Thanks,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
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.



--
Alberto.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Julian
In reply to this post by Joachim Breitner-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Damian Nadales
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Alexey Raga
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Damian Nadales
BTW, when making the distinction between simple and easy I was
referring to this talk:
    https://www.infoq.com/presentations/Simple-Made-Easy

So when I say I would prefer a simple approach, I say that I won't
mind having to spend one month to understand it, as long as I can
write "sustainable programs" (reasonably efficient, extensible,
maitainable, robust, etc).

On Wed, Oct 19, 2016 at 3:13 PM, Alexey Raga <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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.
>
>
> _______________________________________________
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Will Yager
Can anyone comment on the use of Purescript-style effect monads as compared to MTL and Free? While I have not used them in practice, they seem to express the "intent" of monad composition a bit more directly than the approaches we use in Haskell.

Cheers,
Will
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Christopher Allen
It's not really more direct. It's an unordered collection of effects
you can use. IME it's a less efficient mtl-style, but YMMV.

Taking an example from a PureScript tutorial:

func :: Eff (console :: CONSOLE, random :: RANDOM) Unit

Can just as easily be:

func :: (MonadConsole m, MonadGimmeRandom m) => m ()

(mangled name so it doesn't overlap with a real class)

There are other differences, but they haven't amounted to much for me yet.

Kmett's Quine has a good example of some homespun mtl-style:
https://github.com/ekmett/quine

On Wed, Oct 19, 2016 at 12:17 PM, Will Yager <[hidden email]> wrote:
> Can anyone comment on the use of Purescript-style effect monads as compared to MTL and Free? While I have not used them in practice, they seem to express the "intent" of monad composition a bit more directly than the approaches we use in Haskell.
>
> Cheers,
> Will
> _______________________________________________
> 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.



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Will Yager
It seems that there are several advantages to the Purescript approach. 

For example, this 

catchException
  :: forall a e
   . (Error -> Eff e a)
  -> Eff (err :: EXCEPTION | e) a
  -> Eff e a
 would be unwieldy to express using typeclasses, requiring at least three constraints. I also find this style easier to read than constraints, as it requires no mental substitution. E.g. if I see 
(Foo m, Bar m, Bar n) => Baz -> <stuff ...> -> m a
When I get to the end of the type, I have to go back to the beginning to figure out what m is. I can't read left-to-right. This happens a lot with constraint-based monad composition. 
Another advantage is that the Purescipt example uses a concrete type, which is often easier to reason about than "ad-hoc" typeclass abstractions like MonadRandom. However, it looks like you still get the flexibility of ad-hoc typeclasses, because you get to pick any function that discharges the effect type in the given effect monad. 
Like I said, I have not used it, but these are what I've noticed from topical observation. 
Apologies for the formatting; copying that code example appears to have confused the iOS mail app. 
Cheers,
Will


On Oct 19, 2016, at 12:26, Christopher Allen <[hidden email]> wrote:

It's not really more direct. It's an unordered collection of effects
you can use. IME it's a less efficient mtl-style, but YMMV.

Taking an example from a PureScript tutorial:

func :: Eff (console :: CONSOLE, random :: RANDOM) Unit

Can just as easily be:

func :: (MonadConsole m, MonadGimmeRandom m) => m ()

(mangled name so it doesn't overlap with a real class)

There are other differences, but they haven't amounted to much for me yet.

Kmett's Quine has a good example of some homespun mtl-style:
https://github.com/ekmett/quine

On Wed, Oct 19, 2016 at 12:17 PM, Will Yager <[hidden email]> wrote:
Can anyone comment on the use of Purescript-style effect monads as compared to MTL and Free? While I have not used them in practice, they seem to express the "intent" of monad composition a bit more directly than the approaches we use in Haskell.

Cheers,
Will
_______________________________________________
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.



--
Chris Allen
Currently working on http://haskellbook.com

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Christopher Allen
With constraint kinds, you can make type synonyms that expand to
constraints, solving your syntactic objection, but I don't want to
discuss those further.


Far as error handling goes, I use MonadCatch/MonadError:
https://hackage.haskell.org/package/exceptions-0.8.3/docs/Control-Monad-Catch.html

Here catch is:

catch :: (Exception e, MonadCatch m) => m a -> (e -> m a) -> m a

Catch implies Throw, so.

This part,

>Another advantage is that the Purescipt example uses a concrete type

I'm not sure I understand. What are you saying is concrete here? You
still have a row of effects which could be any valid handler. I don't
think I understand the distinction you're making. Eff itself is
parameterized by the row of effects (# !) and the return type (*), so
there's nothing especially "concrete" about that to my mind as
contrasted with something instantiable as any Monad known to have a
Console API and a means of furnishing random values.

On Wed, Oct 19, 2016 at 1:41 PM, Will Yager <[hidden email]> wrote:

> It seems that there are several advantages to the Purescript approach.
>
> For example, this
>
> catchException
>   :: forall a e
>    . (Error -> Eff e a)
>   -> Eff (err :: EXCEPTION | e) a
>   -> Eff e a
>
>  would be unwieldy to express using typeclasses, requiring at least three
> constraints. I also find this style easier to read than constraints, as it
> requires no mental substitution. E.g. if I see
>
> (Foo m, Bar m, Bar n) => Baz -> <stuff ...> -> m a
>
> When I get to the end of the type, I have to go back to the beginning to
> figure out what m is. I can't read left-to-right. This happens a lot with
> constraint-based monad composition.
>
> Another advantage is that the Purescipt example uses a concrete type, which
> is often easier to reason about than "ad-hoc" typeclass abstractions like
> MonadRandom. However, it looks like you still get the flexibility of ad-hoc
> typeclasses, because you get to pick any function that discharges the effect
> type in the given effect monad.
>
> Like I said, I have not used it, but these are what I've noticed from
> topical observation.
>
> Apologies for the formatting; copying that code example appears to have
> confused the iOS mail app.
>
> Cheers,
>
> Will
>
>
>
> On Oct 19, 2016, at 12:26, Christopher Allen <[hidden email]> wrote:
>
> It's not really more direct. It's an unordered collection of effects
> you can use. IME it's a less efficient mtl-style, but YMMV.
>
> Taking an example from a PureScript tutorial:
>
> func :: Eff (console :: CONSOLE, random :: RANDOM) Unit
>
> Can just as easily be:
>
> func :: (MonadConsole m, MonadGimmeRandom m) => m ()
>
> (mangled name so it doesn't overlap with a real class)
>
> There are other differences, but they haven't amounted to much for me yet.
>
> Kmett's Quine has a good example of some homespun mtl-style:
> https://github.com/ekmett/quine
>
> On Wed, Oct 19, 2016 at 12:17 PM, Will Yager <[hidden email]> wrote:
>
> Can anyone comment on the use of Purescript-style effect monads as compared
> to MTL and Free? While I have not used them in practice, they seem to
> express the "intent" of monad composition a bit more directly than the
> approaches we use in Haskell.
>
>
> Cheers,
>
> Will
>
> _______________________________________________
>
> 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.
>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Richard Wallace
In reply to this post by Christopher Allen
I would call the approach in quine a lensy-mtl style. It's ok as far as it goes, but since you are using concrete environment values it isn't great if you want to do testing of things like database code without having a "real" backend hooked up. The typical approach then is to create your own type-class and instances

  class MyBackend where ...

  instance (MonadReader r m, HasDb r) => MyBackend m where ...

  instance (MonadState s m, HasTestState s) => MyBackend m where ...

Of course, now our problem is that our module with this abstraction depends on the module with the db and the test state. Unless we create orphan instances, which I prefer to avoid. This is one area where I like the Free monad approach more because the interpreter can be built and composed with other interpreters in completely separate modules or packages because they are just values.

Rich

PS for the record, I don't strongly prefer the mtl style or the free monad style, I think they each have good qualities and bad and which one I choose tends to depend on other factors.

On Wed, Oct 19, 2016 at 10:26 AM, Christopher Allen <[hidden email]> wrote:
It's not really more direct. It's an unordered collection of effects
you can use. IME it's a less efficient mtl-style, but YMMV.

Taking an example from a PureScript tutorial:

func :: Eff (console :: CONSOLE, random :: RANDOM) Unit

Can just as easily be:

func :: (MonadConsole m, MonadGimmeRandom m) => m ()

(mangled name so it doesn't overlap with a real class)

There are other differences, but they haven't amounted to much for me yet.

Kmett's Quine has a good example of some homespun mtl-style:
https://github.com/ekmett/quine

On Wed, Oct 19, 2016 at 12:17 PM, Will Yager <[hidden email]> wrote:
> Can anyone comment on the use of Purescript-style effect monads as compared to MTL and Free? While I have not used them in practice, they seem to express the "intent" of monad composition a bit more directly than the approaches we use in Haskell.
>
> Cheers,
> Will
> _______________________________________________
> 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.



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Christopher Allen
Oh fair enough, I usually call the partially concreted or lensy style
"mtl-style" and then call MonadReader/MonadState "mtl library". I lean
to the former and usually use the latter if it discharges something I
need right then and there. I've only used Free for something I needed
to aggressively simulate/mock, and even then, some production uses of
Free have gotten defenestrated in favor of something more ordinary.

On Wed, Oct 19, 2016 at 3:47 PM, Richard Wallace
<[hidden email]> wrote:

> I would call the approach in quine a lensy-mtl style. It's ok as far as it
> goes, but since you are using concrete environment values it isn't great if
> you want to do testing of things like database code without having a "real"
> backend hooked up. The typical approach then is to create your own
> type-class and instances
>
>   class MyBackend where ...
>
>   instance (MonadReader r m, HasDb r) => MyBackend m where ...
>
>   instance (MonadState s m, HasTestState s) => MyBackend m where ...
>
> Of course, now our problem is that our module with this abstraction depends
> on the module with the db and the test state. Unless we create orphan
> instances, which I prefer to avoid. This is one area where I like the Free
> monad approach more because the interpreter can be built and composed with
> other interpreters in completely separate modules or packages because they
> are just values.
>
> Rich
>
> PS for the record, I don't strongly prefer the mtl style or the free monad
> style, I think they each have good qualities and bad and which one I choose
> tends to depend on other factors.
>
> On Wed, Oct 19, 2016 at 10:26 AM, Christopher Allen <[hidden email]>
> wrote:
>>
>> It's not really more direct. It's an unordered collection of effects
>> you can use. IME it's a less efficient mtl-style, but YMMV.
>>
>> Taking an example from a PureScript tutorial:
>>
>> func :: Eff (console :: CONSOLE, random :: RANDOM) Unit
>>
>> Can just as easily be:
>>
>> func :: (MonadConsole m, MonadGimmeRandom m) => m ()
>>
>> (mangled name so it doesn't overlap with a real class)
>>
>> There are other differences, but they haven't amounted to much for me yet.
>>
>> Kmett's Quine has a good example of some homespun mtl-style:
>> https://github.com/ekmett/quine
>>
>> On Wed, Oct 19, 2016 at 12:17 PM, Will Yager <[hidden email]> wrote:
>> > Can anyone comment on the use of Purescript-style effect monads as
>> > compared to MTL and Free? While I have not used them in practice, they seem
>> > to express the "intent" of monad composition a bit more directly than the
>> > approaches we use in Haskell.
>> >
>> > Cheers,
>> > Will
>> > _______________________________________________
>> > 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.
>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>> _______________________________________________
>> 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.
>
>



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Will Yager
In reply to this post by Christopher Allen

On Wed, Oct 19, 2016 at 3:19 PM, Christopher Allen <[hidden email]> wrote:

Here catch is:

catch :: (Exception e, MonadCatch m) => m a -> (e -> m a) -> m a


In my mind, this is inferior to the Purescript example, because you have not discharged the MonadCatch instance. That is to say, the result monad continues to have a MonadCatch instance, even though we may want to explicitly express that we have *already* caught any exceptions, so the result type need not be a MonadCatch.

In the Purescript example, the result monad no longer has the EXCEPTION effect, so you have demonstrated statically that the exception has already been caught! This is very useful. You can't express this in the style you're advocating  (which, to be clear, is the style I use most of the time).

In other words, the purescript approach has the benefits of both explicitly enumerating the entire monad transformer stack (you can statically determine exactly which effects are possible *and* which are not, and you can discharge individual layers of the stack) and of using typeclass constraints (you aren't typing out redundant information and you don't have to specify where in the monad transformer stack the effect is handled). It's the best of both worlds.
 

>Another advantage is that the Purescipt example uses a concrete type

I'm not sure I understand. What are you saying is concrete here?

I should have been more clear; the type is polymorphic, but does not have any constraints outside of the type. This isn't a formal advantage so much as a psychological/syntactic advantage. As I said, it's inconvenient to have to mentally sub in constraints on the LHS of the "=>" into the type variables on the RHS of the "=>". The Purescript approach is easier to read for me, even though I've been using the typeclass approach for years.


Like I said, I haven't actually used Purescript, so I'm sure there are additional use cases I'm missing. But this is what stands out.

Cheers,
Will




_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: MTL vs Free-monads, what are your experiences

Julian
In reply to this post by Damian Nadales
Damian Nadales:
> 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.
>

I care about simplicity too, but my interpretation might be slightly
different. I also focus more on the things that a "normal" programmer
cares about without going into esoteric use cases and technical properties.

What I want wrt effects in haskell is:
1. easy to construct (MTL is built on top of transformers, so you get
the same rat-tail there)
2. dynamic: most, of the time I don't care about the ordering of effect
layers
3. no liftXY boilerplate code (freer [0] can do that to some extent with
type inference)
4. being able to add and remove effects without it screwing too much
with my internal API

Basically, it must be declarative, intuitive and non-intrusive.

For some reason, I lean more towards freer/EE here. But it's more like
hope. We tried to make more complicated use of IO subtyping with freer
and it turned out to be rather complicated [1].

Also, afair, edwardk wasn't particularly overwhelmed by the new EE
approach [2].


[0] https://hackage.haskell.org/package/freer
[1] https://gitlab.com/queertypes/freer/issues/7
[2]
https://www.reddit.com/r/haskell/comments/387ex0/are_extensible_effects_a_complete_replacement_for/crt1pzm
_______________________________________________
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.