AP2 makes laziness easy.

Tab Atkins Jr. jackalmage at gmail.com
Mon Aug 26 09:17:50 PDT 2013


On Mon, Aug 26, 2013 at 8:54 AM, Mark S. Miller <erights at google.com> wrote:
> Since today this code will still typically work, and will in the near future
> successfully become lazier, we should expect a lot of such code to exist by
> the time we roll out our new standard. This brings us back to our need to
> chose between "compat-duck", where thenable is simply (typeof obj.then ===
> 'function'), and "narrow-duck", where some additional marking is required.
>
> If we wish to go with narrow-duck, we need to agree on and promote that
> additional marking asap, before more such code accumulates, or we need to
> give up on narrow-duck. We are faced not just with the legacy of all the
> existing promise libraries that would need to add this additional marking to
> their promises. We are also faced with all the users of these promise
> libraries who hand-roll their own thenables as above, to be assimilated by
> these promise libraries.
>
> IMO, I expect it is already too late for narrow-duck, and that we will find
> we are already stuck needing to standardize compat-duck, even though it will
> misinterpret some other existing non-thenable uses of "then".

Yes. I hate it, because it's a terrible stomping all over the object
namespace, but I think we do have to accept that "promise-like" means
"thenable".  ;_;

Note, though, that .flatMap() won't recognize a thenable as a promise.
 There's no "promise-like" where flatMap() is concerned, because
flatMap() is the monadic operation, and should be shared by all
monads, so you have to distinguish types nominally rather than
structurally.  (Or by using a side-channel structural check, like a
brand, which blends the boundaries between the two.)

This means that returning a thenable from a flatMap() callback will
cause a TypeError rejection of the output promise.  What about
.resolve()?

~TJ


More information about the es-discuss mailing list