Why do JS Promise A+ create/fulfill/reject not part of the spec?

Question

http://promisesaplus.com/

Finally, the core Promises/A+ specification does not deal with how to create, fulfill, or reject promises, choosing instead to focus on providing an interoperable then method. Future work in companion specifications may touch on these subjects.

As a functional developer, I usually deal with monads and operators like point bind map or flatMap to chain calls that are wrapped inside some monad box.

According to this question Js Deferred/Promise/Future compared to functional languages like Scala, the map and flatMap operators seems to be melted together under then in the js spec, probably because it would not make so much sense to provide both in a dynamically typed language like Js (?) and it is more convenient to use and remember a single operator.

---

So far so good, there's a then operator (that doesn't seem to always be properly implemented)

But why do the promise create / fulfill / reject is not part of the spec? It's like just having an half a monad :( It seems I'm not the only one to complain

Typically, my problem is:

• I want to create a JS library
• I want to expose a promise-based API
• I want the client to choose the promise implementation he wants to use

Now what am I supposed to do?

I can create promises in my library like

Q.fcall(function () {
    return 10;
})

Ok cool, I just coupled my library to Q :(

So, is there any solution to this problem? How a library author is supposed to create the promises he exposes to the API without coupling to the implementation?

Is there some license-free minimum viable promise A+ library that we can embed in our libraries or something?

What are the reasons behind this spec choice?

Answer 1

What are the reasons behind this spec choice?

As Ben points out in the comments, the idea of the Promises/A+ specification is not to provide some sort of library API. It's to provide a minimum interoperable set of primitives so that anyone who consumes a promise can depend on it having a uniform interface. This is especially important for cross-library interop e.g. at the seams of different components of an application, where different promise libraries may be in use internally. Specifying the full API for a promise library isn't really necessary to meet this goal.

Is there some license-free minimum viable promise A+ library that we can embed in our libraries or something?

There are many Promises/A+ implementations. I don't think any of them are license-free, which is a good thing, because then they'd be by default all rights reserved by their authors. Most (all?) of them are open-source licensed, though, which should be fine.

How a library author is supposed to create the promises he exposes to the API without coupling to the implementation?

I literally do not understand how this would be possible. If you rephrase this question, you are asking, "how do I create a promise, without using a promise implementation?" That's just plain not possible.

• I want to expose a promise-based API
• I want the client to choose the promise implementation he wants to use

This goal, on the other hand, is a different story. If you want to allow people to choose promise implementations, then there are a couple easy options.

First, just return a promise of any implementation; the consumer can convert it to their preferred one using their library's coercion methods. E.g. if your library returns a when promise and I, the consumer, want a Q promise, I can just do Q(yourLibrary.getPromise()).

Alternately, you could allow any library that follows the Promises/A+ constructor proto-spec. This is largely a de-facto standard by now; most major libraries, including the promises built into ES6, follow that specification. So for example you could allow users to do yourLibrary.Promise = Q.Promise, and then inside your library use the assigned promise constructor to create promises.