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 .
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.
"Monads allow us to write imperative code in a functional setting" - the most useful explanation of monads that I've ever heard.
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 .
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.
This talk/demo with OCaml was more understandable to me ua-cam.com/video/z8SI7WBtlcA/v-deo.html
Wonderful introduction to effect systems. I'm currently bumping against mtl edges; I think I'll give fused-effects a try.
Great talk! I'd like to try this to implement a modular monolith.
Cool stuff!
What's the "guard" function at 9:12?
That is equivalent to this, which some people find it easier to read: [(a, b, c) | a
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
Great talk
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.