In Monad & Functor laws, what does "equals" mean?

[kennknowles]

This is one half JS joke and one half math joke.

But even so, I'm only half joking. Maybe it would be good to spell it out, since you probably mean a kind of extensional equality that Javascript is not powerful enough to express.

[puffnfresh]

Yes. This is tricky.

[kennknowles]

Importing discussion with @Twisol about equality and the event loop.

My understanding of what has been said:

• Promises/A+ forbids the argument to then to be called synchronously.
• Depending on the notion of equality, the monad laws may require the argument to then to be called synchronously.
• @Twisol has experienced challenges that led to distinguishing Present and Future promises, in order to have predictable ordering of side effects.

My suggestion is to work out a notion of equality for promises that allows the laws to hold regardless of synchrony, and to order side effects with the usual concurrency control mechanisms. The notion of equality must not forbid such mechanisms from working - waiting on a mutex before delivering a value should be equivalent to delivering it immediately.

The implication for Fantasy Land is simply that equality should be defined by the monad/functor/values in question, and that side effects remain up to the programmer to sort out.

[Twisol]

Just to clarify, you advocate pushing the issue of side-effects downstream to the individual monad implementations?

[kennknowles]

Exactly.

[Twisol]

Okay. I don't really have a problem with that, but I would hate to see a monad implementation that didn't adequately address it somehow.

[kennknowles]

I agree with the concern. In the case of promises + concurrency side effects the two are clearly intimately related so worth discussion in the docs for any implementation of promises.

But I would expect most monad implementations to pass the buck downstream to users, especially data-oriented monads such as List, Maybe, Either, or the free monad. Wouldn't make much sense to talk about side effects in those cases; hopefully programmers know what they are getting into when they use side-effects in a list comprehension (I do this all the time via knockout + underscore).

But I want to emphasize that this issue is a necessary discussion in all cases, even the very simple ones, because [1, 2, 3] === [1, 2, 3] is false, as is {inLeft: 1} === {inLeft: 1}

[Twisol]

That's fair. I think we should have a section of the spec on things that must be addressed somehow downstream, even if we don't prescribe a particular approach. These things seem to come up because of the imperative domain, and they can't be naively ignored.