refactor: avoid FreeM.fold in favor of liftM

[eric-wieser]

simp is more powerful if we express the effects in the existing lean monad transformer stack.

The two minor warts here are:

• we need a big stack of runs to escape the stack
• the associativity of the underlying product representation is flipped around

[eric-wieser]

cc @tannerduve

[tannerduve]

cc @tannerduve

looks reasonable to me

[Shreyas4991]

I am confused. I thought the whole point of Eff was to not worry about monad transformer stacks.

See :

1. https://okmij.org/ftp/Haskell/extensible/exteff.pdf
2. https://github.com/hasura/eff

[tannerduve]

I am confused. I thought the whole point of Eff was to not worry about monad transformer stacks.

See :

1. https://okmij.org/ftp/Haskell/extensible/exteff.pdf

2. https://github.com/hasura/eff

hm this is true. if we are going to interpret into a monad transformer we may as well have just written everything in the monad transformer and not used a free monad at all.

the free monad here was inspired by the extensible effects paper, and the idea is that it provides an alternative (and more flexible) way to combine effects, by taking a free monad over a sum of functors (representing effects) and folding into any type for which you can define an algebra.

i would argue in fact that fold is often preferred, because of the flexibility. you can customize your semantics whereas liftM specifically answers how to run your computations in a particular monad M. often times you may want this but i don't think it should be the default, as they are two different use cases

sorry for my hasty approval i figured a change to the test file was harmless and was not considering my initial motivation in that section. @eric-wieser i wouldn't be surprised if simp can be made more powerful by rearranging the simp lemmas in these files such as in your other PRs, since i was not thinking much about this when writing it. but i think maybe this change should hold off.