Killing `Promise.fulfill`

Kevin Smith zenparsing at
Tue Aug 20 06:57:10 PDT 2013

> The "earlier" you are talking about, IIUC, is the monadic promise variant.

I don't like using the term "monadic" because it sounds pointy-headed : )

> Monads are fine things, and a monadic promise=like abstraction would
> probably be useful for some things. However, it is a very different
> abstraction and it does not support the .then oriented patterns that JS
> promises are used with.

I question this assertion.

A general promise:  P0<P...<Pn<V>>>

Yes - Q does perform recursive unwrapping of the callback return value.
 But Q provides no "fulfill" equivalent.  There is absolutely no way to
create a Q promise where n > 0.  The only way to observe Q's recursive
unwrapping behavior is by handing it a foreign promise where n > 0.  That
case (as far as I know) is rare.

Essentially then, Q lives in a universe where n = 0 for all P.  The "then"
usage patterns are therefore agnostic with respect to recursive unwrapping.

I think perhaps the correct place for recursive unwrapping is a helper
function (perhaps "when") defined on the Promise constructor.  This
function would normalize any input to a promise where n = 0.  I argue that
this is what is wanted for the AsyncTable use case.

    class AsyncTable<t,u> {

        constructor() {
            this.m = Map<t,u>();

        set(keyP :Ref<t>, val :Ref<u>) {
            Promise.when(keyP).then(key => { this.m.set(key, val) });

        get(keyP :Ref<t>) :Promise<u> {
            return Promise.when(keyP).then(key => this.m.get(key));

Note that I've simply replaced "Q" with "Promise.when" from your original
example.  We are basically just coercing an arbitrary type to P0<V>.  We
will always want to use this kind of coersion when accepting arbitrary
input and need an n = 0 promise.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list