MTL vs Free-monads, what are your experiences

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

MTL vs Free-monads, what are your experiences

oleg-30

Matt wrote:
> The mtl technique subsumes the free monad technique. if you have a term:
> getCurrentTime :: MonadClock m => m UTCTime

The relationship between MTL and Free(r) monad approaches is filled
with confusion, as you message has just demonstrated. There is nothing
specific to MTL in writing the constraints like MonadClock. There is
absolutely nothing that prevents you from defining

        instance Member ClockEffect r => MonadClock (Eff r)

or similar with Free monads,
        instance MonadClock (Free CurrentTimeF)

(which are less efficient, compose less well and require the
boilerplate of writing functor instances).

In short, defining constraints like MonadClock, MonadState etc. is not
specific to any approach to effects.  The difference between the monad
transformer and Free monad is how you build types that satisfy the
MonadClock etc. constraint. In MTL, you build by applying monad
transformer to a suitable base monad. In Free monad, you define
functors like CurrentTimeF and then build the Free monad.

In Freer monad approach, your example getCurrentTime will look like
        getCurrentTime :: Member ClockEffect r => Eff r UTCTime
which looks quite like
        getCurrentTime :: MonadClock m => m UTCTime
in your example. Therefore, there is usually no need to define a
separate MonadClock class. But nothing stops you from doing that.

_______________________________________________
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

John Wiegley-2
>>>>> "O" == Oleg  <[hidden email]> writes:

O> and require the boilerplate of writing functor instances

Just note, since DeriveFunctor there is almost never any such boilerplate in
these cases.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
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
There may be another third way to encode effects: 

Maybe it is possible to demonstrate that every effect may be a combination of state (data) and continuations (processing).  I don´t know if this is true, but it is very likely.

If a monad can handle user defined states (in a pure way, like the state monad) and continuations, then the programmer can  implement any new effect by combining them. 

 With continuation effect I mean that each monadic statement can inspect and make use of his own computation in which it is inserted (his closure) and his continuation.

The effects are added by creating new primitives, instead of  aggregating new monad transformers (mtl) or declaring new effects (the free monad).

I implemented reactivity, backtracking, streaming and other high level effects besides readers, writers  and other conventional effects using this approach, in the package transient.

The advantage is  Expressive power (high level effects), composability, simple type signatures,  and extensibility by means of a single expression.

It may be necessary to have more than one monad when we want to enforce certain effects that are performed when one monad is converted into to another, trough the type system

2016-10-16 2:28 GMT+02:00 John Wiegley <[hidden email]>:
>>>>> "O" == Oleg  <[hidden email]> writes:

O> and require the boilerplate of writing functor instances

Just note, since DeriveFunctor there is almost never any such boilerplate in
these cases.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
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.