Alternative interfaces and Lazy promises

[junosuarez]

I've had some conversations lately around lazy promises, for example being able to express a pipeline of operations on promised future values independently of initiating evaluation of the underlying value.

Some ideas around this have included requiring a .done method to terminate a chain of promises, which could propagate up the promise chain to force the evaluation of a lazy promise resolver.

In light of recent "fantasy land" promise discussions, does anyone have any insight around how hypothetical monadic promises might approach this? Similar to Cancel and Progress, Lazy promises are very useful in some situations (eg, for expensive IO operations which may or may not be necessary), but not in every situation.

[domenic]

I think lazy promises is an interesting idea worth exploring, although I think monads are orthogonal. I like the .done terminator for simplicity, although something based on promise pipelining like Q's internal messaging structure also seems like a good direction.

As always, one question worth asking---especially for something as experimental as this---is what would be gained by specifying, instead of working in library space. One potential answer is that lazy promises could be branded (e.g. .then.lazy), which would allow other implementations to treat them differently ... somehow. But whether that'll actually matter depends on the concrete proposal.

For the record, previous related discussions have taken place in:

• Lazy promises (making done compulsory) unhandled-rejections-spec#8
• Hot/Cold promises constructor-spec#8

[bergus]

Similar to Cancel

somehow implementation-specific

That's true. I think if we should specify something like that, we should do it in a more generic way - allowing different promise implementations work together even if they do not support all of such features.

My proposal would be message channels in which events can bubble up and down the promise chain, letting consumers interact more closely with the resolution process.

Examples for down-messages:

• start resolution of lazy promises
• cancel resolution of running promises
• stop/go resolution process
• …

Examples for up-messages:

• basically everything progress callbacks were designed for
• feedback from invoking above actions
• …

A conforming implementation would not need to support all of these possible actions, but would need to transport the messages.

[junosuarez]

@bergus So, basically incorporating a duplex event stream into the promise interface? That's nice and generic, but it seems to greatly increase the scope and requires coordination between promise consumers and promise publishers/resolvers - essentially, an ad-hoc messaging protocol.

[ForbesLindesay]

@bergus, it's an interesting idea, but it needs to be experimented with in user land via libraries before we try and spec it in my opinion.

It's worth noting that the two discussions @domenic links to describe 2 very different sorts of lazy promises.

1. lazy promises that stay lazy until triggered via .done. These are not promises/A+ compatible and will break when used with things like all since they will never have their .done method called. These promises can do a better job of reporting all un-handled rejections.
2. lazy promises that stay lazy only until triggered via .then. These are promises/A+ compatible in every way. They are not, however, resolvers/A+ compatible, since the resolver factory typically runs asynchronously.

[xml]

I hope I'm not intruding, or re-hashing old ground. But rather than making substantial additions/changes to the existing promise object and its methods, what about a new kind of LazyPromise object, which would make the different behavior explicit? Something that functions as almost just a lazy wrapper for a standard Promise? Perhaps along the lines of what James Coglan articulates, near the end of this post?