On 2017-04-17 16:56, David McClain wrote:
Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp.
Beware that Crockford's understanding of monads itself has been questioned (based on this talk). It's been ages since I saw his video and don't feel inclined to watch it again, but I fancy myself as someone who _does_ understand monads[1] and can remember that his presentation seemed *incredibly* fuzzy and imprecise. This might give one the impression that they do understand, when they really don't. I'm not saying that's the case here, but it's something that anyone watching his video should be aware of. The only way to be sure is to try to implement some monads and monad transformers for yourself. (I'd be absolutely *terrified*, personally, of doing it in a unityped langauge because there are *so* many ways to get it subtly wrong and not know it until you hit exactly the "right" edge case. Heck, I even find it somewhat scary in Scala because it's rather easy to accidentally do something impure -- though if you're abstract about your types, you can usually avoid such accidents.) Btw, from my perspecitve the thing that makes monads work for arbitrary side effects is really *data dependencies* + the fact that IO is a sort of "fake" State World monad where you pretend that you always fully evaluate the World argument to the "next step". For anything non-IO it's really just a way to do arbitrary *control flow* based on runtime values -- whereas e.g. Applicative doesn't let you do that[2]. A more direct approach would be Algebraic Effects. Regards, [1] At least at an "intermediate" level. If you just go by the type signatures and desugaring it doesn't seem all that complicated to me, but whatever. I've always been inclined towards algebra/symbol manipulation, so maybe it's just me. [2] You can kind of simulate it, but you basically end up evaluating everything and "wasting computation" by redundant evaluation. You can think of it as always having to evaluate both branches of all if's and then choosing the result afterwards. Obviously, that doesn't work if you have *actual* side effects.