Simon Peyton Jones

Map says I apply a function to every element of the list.

Well, so it has type A to B to list of A to list of B. If you want to apply an IO performing function, so the function you're applying has type like int to IO of char, you could map that over a list, but you just get a list of IO of chars.

That hasn't done any IO yet, right?

You want something that says, take a list of I-O chars and perform those actions one at a time.

So I want a function that goes from type list of I-O char to I-O of list of char, right?

And you might want to perform all those actions top to bottom or maybe bottom to top.

Who knows?

That's what this function of type, you know, so yes, so you could do it in various ways.

So sometimes it gets in the way, right?

You say, oh, shit, you know, can't I just use map?

Well, in Haskell, no, sorry.

You're going to have to do a little bit more work to tell me in what sequence you want your effects to happen.

Because by default, Haskell does not specify sequence.

So adding monads to control effects does get in your face a bit.

And that's the tax we pay.

In effect, that's part of the big experiment that Haskell is doing, is to say, suppose we up front say we're willing to pay that tax.

How many followers can we get?

I will note that monads have infected quite a lot of other languages.

F-sharp is definitely called by value impure language, and yet F-sharp had these workflows that were definitely monads.

Monads have appeared in Scalo and in many other languages.