UDATE.
See this new library
proving functor and monad operators
for plain callback-based functions
that do not have the issues with theneables
as outlined below:

https://github.com/dmitriz/cpsfy

## The JS Promise is neither a Functor nor an Applicative nor a Monad

It is not a functor, because the
composition preservation law
(sending compositions of functions to compositions of their images)
is violated:

```
promise.then(x => g(f(x)))
```

is NOT equivalent to

```
promise.then(f).then(g)
```

What this means in practical terms,
it is never safe to refactor

```
promise
.then(x => f(x))
.then(y => g(y))
```

to

```
promise
.then(x => g(f(x))
```

as it would have been, were `Promise`

a functor.

**Proof of the functor law violation.** Here is a counter-example:

//Functor composition preservation law:
// promise.then(f).then(g) vs promise.then(x => g(f(x)))
// f takes function `x`
// and saves it in object under `then` prop:
const f = x => ({then: x})
// g returns the `then` prop from object
const g = obj => obj.then
// h = compose(g, f) is the identity
const h = x => g(f(x))
// fulfill promise with the identity function
const promise = Promise.resolve(a => a)
// this promise is fulfilled with the identity function
promise.then(h)
.then(res => {
console.log("then(h) returns: ", res)
})
// => "then(h) returns: " a => a
// but this promise is never fulfilled
promise.then(f)
.then(g)
.then(res => {
console.log("then(f).then(g) returns: ", res)
})
// => ???
// because this one isn't:
promise.then(f)
.then(res => {
console.log("then(f) returns: ", res)
})

Here is this example on Codepen:
https://codepen.io/dmitriz/pen/QrMawp?editors=0011

## Explanation

Since the composition `h`

is the identity function, `promise.then(h)`

simply adopts the state of `promise`

, which is already fulfilled with the identity `a => a`

.

On the other hand, `f`

returns the so-called *thenable*:

1.2. “thenable” is an object or function that defines a then method.

To uphold the functor law, `.then`

would have to simply wrap into promise the result `f(x)`

. Instead, the Promise Spec requires a different behavior when the function inside `.then`

returns a "thenable". As per 2.3.3.3, the identity function `id = a => a`

stored under `then`

key is called as

```
id(resolvePromise, rejectPromise)
```

where `resolvePromise`

and `rejectPromise`

are two callback functions provided by the promise resolution procedure. But then, in order to be resolved or rejected, one of these callback functions must be called, which never happens! So the resulting promise remains in the pending state.

## Conclusion

In this example,
`promise.then(x => g(f(x)))`

is fulfilled with the identity function `a => a`

,
whereas
`promise.then(f).then(g)`

remains in the pending state forever.
Hence these two promises are not equivalent
and therefore the functor law is violated.

Because even the natural transform law from the Pointed Functor Spec, that is part of being Applicative (the homomorphism law), is violated:

```
Promise.resolve(g(x)) is NOT equivalent to Promise.resolve(x).then(g)
```

**Proof.** Here is a counter-example:

// identity function saved under `then` prop
const v = ({then: a => a})
// `g` returns `then` prop from object
const g = obj => obj.then
// `g(v)` is the identity function
Promise.resolve(g(v)).then(res => {
console.log("resolve(g(v)) returns: ", res)
})
// => "resolve(g(v)) returns: " a => a
// `v` is unwrapped into promise that remains pending forever
// as it never calls any of the callbacks
Promise.resolve(v).then(g).then(res => {
console.log("resolve(v).then(g) returns: ", res)
})
// => ???

This example on Codepen: https://codepen.io/dmitriz/pen/wjqyjY?editors=0011

## Conclusion

In this example again one promise is fulfilled, whereas the other is pending, therefore the two are not equivalent in any sense, violating the law.

UPDATE.

## What does exactly "being a Functor" mean?

There seems to be a confusion between Promise **being** a Functor/Applicative/Monad as it is, and ways to **make it such** by changing its methods or adding new ones. However, a Functor must have a `map`

method (not necessarily under this name) already provided, and being a Functor clearly depends on the choice of this method. The actual name of the method does not play any role, as long as the laws are satisfied.

For the Promises, `.then`

is the most natural choice, which fails the Functor law as explained below. None of the other Promise methods would make it a Functor either in any conceivable way, as far as I can see.

## Changing or adding methods

It is a different matter whether **other methods** can be defined that conform to the laws. The only implementation in this direction that I am aware of is provided by the creed library.

But there is a **considerable price to pay**: not only entirely new `map`

method needs to be defined, but also the promise objects themselves need to be changed: a `creed`

promise can hold a "theneable" as value, while the native JS Promise can't. This change is substantial and necessary to avoid breaking the law in the examples as one explained below. In particular, I am not aware of any way to make the Promise into a Functor (or a Monad) without such fundamental changes.

justa function of type`(a -> b) -> C a -> C b`

; it is also a set of laws which apply to said function (likewise for applicative functors and monads - furthermore these additionally require a function`a -> C a`

). You say that "googling I found out that ..." but not where you've found this claim, or what the reasoning there was.`bind`

correctly, but unfortunately do not correctly implement`map`

or`pure`

due to their recursive flattening. They do however form a valid applicative, monadic functor over the restricted category of non-thenable types.