[Haskell-cafe] Wow Monads!

Bardur Arantsson spam at scientician.net
Mon Apr 17 18:12:10 UTC 2017

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.


[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.

More information about the Haskell-Cafe mailing list