MTL vs Free-monads, what are your experiences

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.

"O" == Oleg
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

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
"O" == Oleg
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.
participants (3)
-
Alberto G. Corona
-
John Wiegley
-
Oleg