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:[email protected]> Sent: 4/25/2013 18:21 To: Mark Miller<mailto:[email protected]>; David Bruant<mailto:[email protected]> Cc: Mark S. Miller<mailto:[email protected]>; es-discuss<mailto:[email protected]> 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 promises. 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. Claus >> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
