A Challenge Problem for Promise Designers (was: Re: Futures)

Claus Reinke claus.reinke at talk21.com
Thu Apr 25 15:21:28 PDT 2013

I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:

1 "library author doesn't want nested Promises."
2 crossing Promise library boundaries can create unwanted nesting

There is little to be said about 1, only that those library authors still 
have a choice: add a separate recursive flattening operation and keep 
the thenable operations unharmed, or give up on Promises being 
thenables in the monad-inspired JS patterns sense (and hence give 
up on profiting from generic thenable library code).

The second point is somewhat more interesting, as it stems from yet
another convenience-driven thenable deviation: if a then-callback does
not return a Promise, its result is implicitly lifted into a Promise; the
unwanted nesting apparently comes from different libs not recognizing 
each others promises, mistaking foreign promises for values, and lifting
them into their own promises. Recursive flattening (assimilation) is
then intended as a countermeasure to recursive lifting of foreign

It will come as no surprise that I think implicit lifting is just as mistaken
and recursive flattening;-) Both should be moved to explicit convenience
methods, leaving the generic 'then'/'of' interface with the properties
needed for generic thenable library code.


>> I think we see a correlation -- not a 1.0 correlation, but something. Those
>> who've actually used promise libraries with this flattening property find
>> it pleasant. Those who come from either a statically typed or monadic
>> perspective, or have had no experience with flattening promises, generally
>> think they shouldn't flatten. 
> I think the dispute could be settled easily: 
> - flattening 'then' is a convenience
> - non-flattening 'then' is necessary for promises being thenables
>    (in the monad-inspired JS patterns sense)
> Why not have both? Non-flattening 'then' for generic thenable
> coding, and a convenience method 'then_' for 'then'+flattening.
> That way, coders can document whether they expect convenience
> or standard thenable behavior. And we can have convenience for
> Promise coding without ruining Promises for more general thenable 
> coding patterns.
> Claus
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss 

More information about the es-discuss mailing list