Killing `Promise.fulfill`

Kevin Smith zenparsing at gmail.com
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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130820/5326aef7/attachment.html>


More information about the es-discuss mailing list