Revisiting application structure

[felixmulder]

Here's a draft of my thoughts on us going to the MonadTransControl approach for MTL.

Here's TODOs:

• Attribute approach to Pepe and get a bit more background on where he came up with it, from "the old place"?
• MonadTransControl vs only MonadTrans?

[felixmulder]

Going sailing tomorrow, so published an initial version of this. Happy to update the attribution paragraphs if there's something else you think I should put there :)

[akrmn]

definitely not my credit to take! This approach was pretty much in place when I joined the team where I saw it. I believe @pepeiborra, @vapourismo and @adamse might have a better picture of the story behind it

[pepeiborra]

When I joined Strats in Jan 2017, the codebase was already making heavy use of type classes for individual effects, e.g. MonadTime, MonadDelay, MonadLog, etc. but there was no solution to the n^2 problem. Monad transformers were providing instances for all the effects, relying on deriving to avoid as much boilerplate as possible. Alexis article takes this approach to the extreme.

I made the point that introducing a new effect class required adding it to the deriving lists of all N transformers, which made engineers unwilling to add effects. and the approach could not scale. My solution to this was the passthrough instance, which requires a MonadTransControl transformer (or MonadtTrans for non-scoped effects). Since all ReaderT transformers are in MonadTransControl by definition unless the environment mentions the base monad, the codebase quickly gravitates towards ReaderT in order to avoid having to write instances manually.

[felixmulder]

Thanks a lot for the insight! Added it to the post and linked to your comment 🙌