"Building Haskell Programs with Fused Effects" by Patrick Thomson

Haskell is a purely functional programming language: by default, Haskell functions do not cause side effects such as system I/O, nondeterminism, or exception handling. As such, Haskell programs are generally expressed in terms of monad transformers, which provide the facility to compose different side effects into a single interface powerful enough to express the programmer's needs. The monad transformer library, mtl, is mature and powerful, but complicates and in some cases constrains the construction and generalization of user-specified monads.
A class of libraries known as 'effect systems' have emerged in an attempt to solve the problems associated with monad transformers. Effect systems provide a compositional approach to program construction, generally using a single monadic type specialzed with a programmer-provided list of capabilities. Effect systems are more powerful and flexible than monad transformers, but their adoption in industry has been minimal, due both to their incompatiblity with mtl and their historically poor performance.
The new fused-effects library changes the status quo: it provides an extensible and flexible vocabulary for program construction, yielding a more expressive interface than mtl without sacrificing any performance characteristics. I'll describe the history of effect systems, outline the tradeoffs associated with programming with effects, and demonstrate the use of fused-effects in practice.
Patrick Thomson
GitHub, Inc.
@importantshock
Patrick is a senior engineer on GitHub's Semantic Code team, building systems to understand and analyze the corpus of code on GitHub. He enjoys peaceful countryside walks and loud rap shows.

[@miraclemaxicl]

"Monads allow us to write imperative code in a functional setting" - the most useful explanation of monads that I've ever heard.

[@virkony]

Thank you for tackling this real-life problem that probably everyone hit in attempt to use Haskell commercially.
I guess there is a reason behind having only one read context per monad. Code referenced at 19:43 as "perfectly valid" still have same limitation, it just says "Hey! Lets refer to value via type", but signature of "ask" still have no way to distinguish between values of same type.
Between half-baked solution for aggregating multiple values behind "ask" authors saw that this responsibility to "index" (either by type or by something else) should be outside of "mtl". No one prevents you from putting class-restricted parameter there and have in class something like class TypeIndexed aggr typ where fetch :: aggr -> typ .

[@messapatingy]

This topic is amazingly interesting for me, but too hard to comprehend. I hope you will provide a tutorial at some point in the not-to-distant future.

[@SeanAubin]

This talk/demo with OCaml was more understandable to me th-cam.com/video/z8SI7WBtlcA/w-d-xo.html

[@LKRaider]

Cool stuff!

[@tepan]

Great talk! I'd like to try this to implement a modular monolith.

[@tc2017]

Great talk

[@LaurentRDC]

Wonderful introduction to effect systems. I'm currently bumping against mtl edges; I think I'll give fused-effects a try.

[@messapatingy]

What's the "guard" function at 9:12?

[@DanielSantaCruz]

That is equivalent to this, which some people find it easier to read: [(a, b, c) | a

[@juanmartin4173]

It's like an assertion (see hackage.haskell.org/package/base-4.12.0.0/docs/Control-Monad.html#v:guard) in the List monad

[@dobotube]

Admirable effort, but also makes it painfully obvious how heavy the cognitive burden of writing effectful code in a pure language is.
And since you need purity in a lazy language, I feel this is a bit of an indictment of Haskell.