> By the very nature of the monad laws, they cannot have side-effects, so they cannot be eager.

I'm pretty sure monads can have side effects and be eager. It's just that not everything will be captured by the type signature. AFAIK this does not prevent it from being a monad. You can have monads without any type signature. Also, AFAIK the eagerness is a requirement due to the potential for errors changing program flow that is not captured by the type signature. But AFAIK this does not prevent it from being a monad.

AFAIK monads only have to conform to the monad laws, bind and return.

I'd like to know if I'm wrong because I'm concerned with the conflation of monads and language features of haskell. Specifically we can benefit from monadic composition without making javascript into haskell. I think Erik Meijer has been rather damaging in this regard. I know I'm in the minority so I'd like to be proven wrong so I can come join the party :)

IO is a monad in Haskell, right?

I mean, we can talk about how it's pure in the sense that it just lifts other things in to being tied to IO programs, and it's our evaluation of them that causes mutation, but that's pedantic even to me and seems to miss the point.

That sense of purity isn't what most people mean or are concerned by.

IO a is short for roughly World -> (a, World) and is thus computationally pure. You cannot figure out what happens to the World in between but you don't need to, thus the side effects "don't exist" from a analysis standpoint.

However IO follows all of the Monadic laws, I believe the comments about side effects are focusing on the side effects that show through when you try and apply the monadic laws to promises.

The "world" equivalence is not a useful way to think about it. A more useful description would be a tuple that contains two items, the first one being the description of the action to execute, and the second one being the function that will be called with the value retrieved with the action executed.

So in JS notation:

  { action: {type: 'readFile', fileName: f}, next: content => mkPrintAction(content) }

> The "world" equivalence is not a useful way to think about it.

Regardless of your opinion on the matter, that's how it's actually implemented. IO is roughly equivalent to "State RealWorld#" with some extra strictness/unboxing stuff.

What you're talking about is basically the free monad over the (Request, Response -> a) functor. That would probably work, but be less performant and harder to extend.

IO is nice because it's really easy to safely integrate with FFI calls. I don't think you could easily do the same with your proposal.

Its just that when you mention this, the assumption is that "World" is the state of the world. Which is not true, since world is just a token to impose ordering of execution in a lazy language, but its a fake state token since its not present at run time... and that complicates the explanation further.

The interpreter is simpler and easy to implement in any language too.

That's true, the compiler does optimize away the explicit dependency on the world. But it still makes sense; when you call "print", it returns a "new world" that is the state of the world after printing. You can't inspect the state of the world, so it doesn't really matter whether it's just a token or an actual description of the universe. The behavior is indistinguishable either way.

That assumes there is only one program running in the world. Its simply not clear what the "world" type means. Its a bad name. I'd rather go ahead and explain it as a token.

I don't see why it assumes there is only one program. If the world value is impossible to inspect (which it is), you can assign whatever semantics you like to it.

If you look at the generated core code, it's important to notice that it's not the same "token" being passed around everywhere. Each IO action returns a new token, which could be a different value from the old token. (Again, this is entirely theoretical, as the token/world state doesn't exist in the binary.)

Ok, I'll put it this way:

Saying

> when you call "print", it returns a "new world" that is the state of the world after printing

makes no sense, since the word "state of the world" will be interpreted completely differently by the receiver of the explanation. State of the world = a large state object with lots of fields describing every single thing in some "World" (what world: program world? computer world? network world? all the world?). Thats what people hear.

The name of the type is horrible, and the world-passing intuition is also horrible. "Token" would've been much better, but its still not clear how to implement or why its even necessary (in a non-lazy language)

On the other hand, a tuple representing the current action and the function that will return the next action (or nil) is fairly clear, easy to implement an interpreter for, the pure/nonpure distinction becomes obvious (the runtime interpreter is the impure part), and laziness doesn't even need to get into the mix.

oh, and also regarding FFI: {type: 'FFICall', fn: string, arguments: [...]}

That's a fair argument. People might get caught up on thinking that the world object actually has to contain a description of the world.

> {type: 'FFICall', fn: string, arguments: [...]}

I agree that this is simpler to understand, but it's no good in practice. It's obviously not type safe, and you still have to bake support into the interpreter/runtime for whatever your string value is. It's also effectively impossible to inline/optimize away. Which, again, is probably why it's done using "State RealWorld#" in GHC.

I would like to reiterate that however RealWorld# happens to be defined, the way its use is enforced in GHC is the exact same as if it did actually contain a description of the entire universe. You just aren't allowed to look at it. But, you are correct, this is more confusing than a request/response free monad.

Honestly I've always just thought of Monads as-in Haskell as a tricky way of sequencing in the presence of lazy evaluation. Looked at this way, the "trick" is to make a data dependency between each step in the form of an argument. Since Haskell names must be bound before they're read this means we can guarantee the order in which the steps are evaluated relative to one another. Then the whole thing is wrapped up in a data structure (this latter part seems to be what people normally focus on).

This is a late reply, but your abstraction is leaky: World might mutate during an IO operation in a way which impacts the outcome. So the (a, World) result isnt fully deterministic from World. Even if you make each IO operation atomic, a chain of IO is still impure because the final (a, World) result depends on mutations introduced during execution.

The lift to constructing an IO program from a Haskell type is pure, but the execution of that program to generate a value or effect on the system is not.

So Haskell is "pure" when it comes to IO, but not in the way anyone except overly pedantic people mean the term.

World cannot be inspected in any meaningful way in this paradigm so it is fully deterministic because the differences aren't important.

> So the (a, World) result isnt fully deterministic from World. Even if you make each IO operation atomic, a chain of IO is still impure because the final (a, World) result depends on mutations introduced during execution.

It is fully deterministic from World but you cannot possibly describe a World so you can't supply it nor replicate it.

> So Haskell is "pure" when it comes to IO, but not in the way anyone except overly pedantic people mean the term.

You can't create a World so it is pedantic in that fashion but you are able to think of the functions as pure otherwise making integration easier.

A simple example is that IO happens in the correct order in Haskell because of the evaluation order not due to some external construct ensuring that lazy doesn't bite you.

Which only goes to show that you can't apply real world reasoning to explain an academic concept. In this purely theoretical concept, World (which cannot be inspected) does contain the entirety of the world, including all other actions running in parallel, the current time and the state of every atom in the universe. So given the exact same state of the universe and assuming purely deterministic laws governing it (or the state of the world containing the future of the world too), yes, the action will produce the exact same output, because all other actions running in parallel or the things that will lead to the future actions are also part of that input World state.

Thats my best attempt, and it still sucks! I bet someone will start wondering about the uncertainty principle there... So lets just use a free monad or thunks in a strict language

  function pureAction() {
    return function() { return impureAction(); }
  }

  function chain(pureAction, fnReturningOtherAction) {
    return function() {
      var impureResult = pureAction();
      var newAction = fnReturningOtherAction(impureResult);
      return newAction();
    }
  }


  function interpreter(mainAction) { return mainAction(); }

Everything is pure, since all the functions don't do anything but return thunks for the interpreter to run. Except the interpreter which actually runs those. This isn't even a theoretical explanation - its exactly how PureScript's Eff works.

Would it be fair to say that the IO Monad get passed along implicitly with the other Monads in an eager evaluating system? Would this make it a stack? Just one that's not represented or enforced by the type system.

I dunno, so much of the IO Monad is specific to Haskell and lazy evaluation. Generally I think of it as Haskell's quirky way of handling the real world in a pure lazy mathematical construct and not something fundamental.

The monad laws are defined in terms of equivalence of values. So if your promise is not a value then you can't even begin to talk about whether it conforms to the monad laws or not. If `Promise(someWebRequest())` starts performing the web request immediately then we can't talk about it as a value (or rather, in order to regard it as a value we have to elide some aspects of it that are actually quite crucial, such as the web request being performed).

Perhaps you're a minority, but you're not alone - I too think that the usual narratives around monads (and many other theoretical CS concepts) are quite harmful. Do not get me wrong - they can all be useful, but not when they are conflated with many other things that some people like to have together with monads.

Well lets see if the first law holds. It says

Promise.resolve(a).then(f) == f(a)

Immediately this is not true, since `f` can throw or return a non-promise.

But lets say we restrict the type of f so that it can only return promises. Once again, the statement is not correct - the executed side effect is not the same. The left side will execute with one tick delay of the microtask queue, while on the right side the side effect executes immediately. So the side effects are not equivalent. If we write `f(a); f(b);` and `Promise.resolve(a).then(f); f(b);`, in the first case the side effects will start in order; in the second case, they will start in the reverse order. If we cannot replace one side of equal sign in the law with the other and have things run exactly the same, that means equational reasoning doesnt work [1], and the law doesn't apply.

In theory you could probably make monads with side-effects, but promises don't satisfy the laws. Its much easier if the monad only represents side effects but doesn't actually run them. You can think of them as redux action objects - they don't actually do anything once they are created. They only represent the side effect that will be run. For example, their internal representation could be {action: 'readFile', argument: 'path/to/file.json'}. ($)

You can construct actions from other actions by chaining them with a function that will take the result from the action and produce a new action object. Those would be derived actions. You can think of them as cons cells - they have the original action, and the function that produces a new action. Example representation: {originalAction: {action: 'readFile', argument: 'path/to/file.json'}, nextActionFunction: result => printLine(result)}

Finally, you pass the action to the "interpreter". The interpreter reads each action, runs the originalAction part of the cons cell, then produces a new actioin using the function in the nextActionFunction cell. It repeats that until it gets to an empty nextActionFunction cell.

($) Anoter practical representation for compile-to-js languages would be to use a thunk for the base (original) action. A thunk is a function without arguments, that when run, will produce a side-effect and return a value. The interpreter would then be simply a thunk runner. An async thunk can also be used, and thats a thunk that takes a callback that will be called with the eventual value. Still, we're only producing values without creating side effects: the laws are much easier to uphold.

[1]: http://www.haskellforall.com/2013/12/equational-reasoning.ht...

The first one is a pretty nitpicking one, IMO; all that's happened is that then/fmap and map have been collapsed into a single function that dynamically dispatches on the type of the returned value to decide which behavior to execute. More of an ergonomic convenience for programmers who don't quite grasp the distinction.

Edit: And with regard to the side effect ordering question -monads are only well-known defined for pure functions anyway! By that standard, any Scala code using non-pure functions is also not using a monad. This I inevitable in a language that does not enforce purity, which is basically every widely-adopted one that's not Haskell. A definition of "support" that excludes implementations that allow (but do not require) non-pure functions is not a very useful definition.

Thats not the issue here. Even if the functions themselves are pure (beyond the act of creating a promise), the strictness of promises together with their micro-task queue rule impose execution ordering that make them a non-monad. So its impossible to write your functions in a way that the laws hold.

And if you can't use the laws for equational reasoning, then what good is it whether its a "monad" or not anyway?

How would it be less of a Monad than the IO Monad? That's the part I'm not getting. It would make sense to me if neither were considered monads.

If the monad laws don't hold, its not a monad. I demonstrated the first law not holding, therefore promises are not a monad.