A Challenge Problem for Promise Designers (was: Re: Futures)
domenic at domenicdenicola.com
Thu Apr 25 15:31:13 PDT 2013
Can you point to any code in wide use that makes use of this "thenables = monads" idea you seem to be implicitly assuming? Perhaps some of this "generic thenable library code"? I have never seen such code, whereas the use of "thenable" to mean "object with a then method, which we will try to treat as a promise" as in Promises/A+ seems widely deployed throughout libraries that are used by thousands of people judging by GitHub stars alone.
Thus I would say it's not promise libraries that are "harming the thenable operations," but perhaps some minority libraries who have misinterpreted what it means to be a thenable.
From: Claus Reinke<mailto:claus.reinke at talk21.com>
Sent: 4/25/2013 18:21
To: Mark Miller<mailto:erights at gmail.com>; David Bruant<mailto:bruant.d at gmail.com>
Cc: Mark S. Miller<mailto:erights at google.com>; es-discuss<mailto:es-discuss at mozilla.org>
Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures)
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.
> es-discuss mailing list
> es-discuss at mozilla.org
es-discuss mailing list
es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss