Thanks, the definition you posted above is helpful. Try evaluating const map = f => bind(x => pure(f(x))); map(pure)(pure(5)) to understand why this is not actually a lawful implementation of bind.
Without having a join operation (which can be recovered as bind(id) from a lawful bind), it's actually meaningless to talk about a "monad". Monads are fundamentally defined by an associative join and an idempotent pure, together forming a monoid.
This isn't about lazy evaluation vs strict evaluation, but rather about pure vs impure evaluation. The term verifyUser(user, password) does not purely evaluate to a representation of an effect; instead it immediately starts performing effects in the course of its evaluation. The result of evaluating it is not dependent only on its inputs, but also on the state of the world.
This means verifyUser isn't actually a function in the functional programming sense of the word, preventing us from reasoning equationally in programs that involve it. For example the following program:
const userDetails = b ? map(just)(verifyUser(user, password)) : pure(nothing)
when using promises. It is when using a lawful asynchronicity monad (e.g. the continuation monad above). Whether this is bad or good depends on whether you prefer an imperative or functional style of reasoning.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks, the definition you posted above is helpful. Try evaluating
const map = f => bind(x => pure(f(x))); map(pure)(pure(5))
to understand why this is not actually a lawful implementation ofbind
.Without having a
join
operation (which can be recovered asbind(id)
from a lawfulbind
), it's actually meaningless to talk about a "monad". Monads are fundamentally defined by an associativejoin
and an idempotentpure
, together forming a monoid.This isn't about lazy evaluation vs strict evaluation, but rather about pure vs impure evaluation. The term
verifyUser(user, password)
does not purely evaluate to a representation of an effect; instead it immediately starts performing effects in the course of its evaluation. The result of evaluating it is not dependent only on its inputs, but also on the state of the world.This means
verifyUser
isn't actually a function in the functional programming sense of the word, preventing us from reasoning equationally in programs that involve it. For example the following program:is not the same program as:
when using promises. It is when using a lawful asynchronicity monad (e.g. the continuation monad above). Whether this is bad or good depends on whether you prefer an imperative or functional style of reasoning.