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 <damian.nadales@gmail.com> 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.