Comment by inglor | Hacker News Reader

Comment by inglor | Hacker News Reader

So much wrong in one place. A promise is the IO monad, with `then` being `>>=` [1].

If you write your promises code not to cause explicit side effects - it won't and you get pure code.

The fact you have (controlled!) side effects is the whole purpose of the IO monad. You can't avoid side effects or your program wouldn't do anything, a promise keeps the side effects in a box (the promise) and lets you code using boxes so that your code is purer. Of course, not all your code can be _actually_ pure because all code needs side effects.

The FUD about async/await is even stranger. JS _has_ async/await, it already shipped in Microsoft Edge (IE) and it's coming to other browsers. It is based on promises (just like it's based on Tasks = Promises) in C#.

The fact people talk so much about this without learning the topic is amazing. I'm genuinely disappointed with the quality of discussion in HN over these topics lately.

Monet is also a bad implementation of the IO monad in JS, in fact it's not an implementation at all. Here is an issue I opened there a while ago: https://github.com/cwmyers/monet.js/issues/25

[1] up to the fact `.then` does both `fmap` and `>>=` through overloading based on the return type. Seriously, if you remove the exceptions and the fact you can return an unwrapped value it's `Promise a -> a -> Promise b -> Promise b` for then's signature (the Promise a being `this`, the a -> Promise b` being the handler and the return value being itself).

> If you write your promises code not to cause explicit side effects - it won't and you get pure code.

The way I've seen promises used in JS is always in this pseudocode form:

- initiate something side effecty (making an HTTP request, for example)

- resolve the promise once the value is ready

Is there something you have in mind for how we'd write promises-based code without side effects in JS?

The same way you'd write "code that doesn't cause side effects" in Haskell. You cause side effects. The thing is with promises (like IO) the side effects are limited to a box you can open, process and close.

So given the same input the same function will always return the same output. If you have a function that asynchronously computes a random number - it won't return different numbers and will always return a promise for a random number. It will never be observable that being called with a different input it produced a different output (as long as you don't mutate global state or anything like that).

In Haskell, IO is implemented in a way that causes side effects at the platform level. If there are no side effects there is nothing going on and the program is a no op after all :) Monads like IO are about _limiting_ side effects and _controlling_ state.

In Haskell, the lack of side effects is by the fact IO is provided by the platform. There is no fundamental difference between Haskell's `getLine` and the DOM's `fetch`, both return a boxed value.

Thanks for the followup!

> In Haskell, the lack of side effects is by the fact IO is provided by the platform. There is no fundamental difference between Haskell's `getLine` and the DOM's `fetch`, both return a boxed value.

In his talk about "effects"[1], Chris Armstrong also talked about making testing easier in Haskell, though I paid less attention to that part, to be honest.

`fetch` returns a promise, but calling fetch causes the side effect to occur immediately. I don't know if that's how `getLine` works in Haskell. If I want to test code that calls `fetch` without an HTTP request actually hitting the network, I need to put in a mock `fetch`.[2]

Or, if there was another return type that put the side effect in a box that the platform handles later (or not at all, in the case of a test), that seems like a win.

[1]: https://www.youtube.com/watch?v=D37dc9EoFus

[2]: another option, pointed out on Twitter, is that a promise (either from the fetch or from the test) could be passed in to the code under test. That seems less pleasant but requires no new machinery.

Fetch doesn't actually make an HTTP call - that's the thing :) Fetch boxes a value so that the _platform_ can make an HTTP call.

You couldn't implement `fetch` yourself without platform APIs and you certainly couldn't do it in JavaScript without the DOM. The second suggestion you pointed (from Twitter) is exactly what you'd do in Haskell (you'd pass an IO from somewhere else). You can call it "pass an effect" if you'd like but it's the same thing :)

Indeed, the platform is responsible for the HTTP call, so I see what you mean. The side effect is happening in the platform itself. I should watch the second part of Chris Armstrong's video to see how he approached making testing nicer in Haskell.

I read the OP's comment as: you can write the "then" functions as pure functions, and they won't have any side effects; those will then be isolated inside the code that resolves the promise - code that you usually don't write yourself as it is part of some library, as with "fetch(...)" for making an HTTP request.

Sure, the `then`s could be pure functions but the whole point of my blog post is that I'd like to be able to test code that calls `fetch`. That would be possible if the actual side effecting operation is deferred to later, and not just the result.

Not sure promises are equivalent to the IO monad in particular. They could form a Monad instance, although that is not the interface they have chosen to expose. It does seem it would be more similar to the `Either` monad, however.

The type signature, with `catch` is something like Either mixed with `IO`, it's just a specific form of continuation[1]. Promises are not _exactly_ like an IO monad because it would not be pragmatic, but it serves the same purpose (controlled side effects and boxing temporal state) in the same way (a bind operator).

If you look at all the examples online for `IO` [2] they all translate 1-1 to promises just fine :)

[1] : http://blog.sigfpe.com/2008/12/mother-of-all-monads.html [2] : for example http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

Oh yeah, I totally agree, the examples for the IO monad match up very well to what can be done with Promises. My point was more that this is the case because the IO monad is the canonical black box monad: All you can do with it stems from its implementation of the monad interface, and so anything that behaves like a Monad will look very similar. This is tantamount to saying that Promises have a potentially useful Monad instance (which I am completely in agreement with you on).

The point about continuations is also a very interesting one, but I think again, stems from the same idea: Almost any monadic interface can be simulated with continuations.

Promises also have a notion of parallel tasking which isn't, at least in my mental model of IO, really IO.

But of course we're talking about IO... so my mental model is just that: mine and mine alone, really.

`Promise a -> (a -> Promise b) -> Promise b` is missing some parenthesis.

Reply on news.ycombinator.com