Do futures represent a pipeline? (was Re: Future cancellation)
On Tue, Apr 30, 2013 at 12:49 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
Thanks, the idea that .then() returns a new Promise is very very strange to me. What gets stored into that promise?
Yes, promises can be through of as pipelines. The return value of .then() is a new promise, which gains its value from the .then() callbacks - if the callbacks return a value, it accepts/resolves with the same value; if they throw, it rejects with the error.
The reasoning behind promises/futures is explained in more detail in my blog posts www.xanthir.com/b4PY0, www.xanthir.com/b4P_0 and Domenic's domenic.me/2012/10/14/youre-missing-the-point-of-promises.
I think I see a lot of the historical confusion here as being rooted in the fact that the terms 'promise' and 'future' seem poorly-suited for describing a pipeline oriented primitive, if that's what these futures are. Maybe all discussion threads on futures need a big hairy disclaimer that tells people to read a description of what 'future' and 'promise' actually mean in this context :)
I think "future" is a pretty good name, personally - it means that the callbacks will be run in the future. ^_^ But "promise" also kinda works, and it's more common. But DOMFuture definitely needs more explanatory text (which I've promised to submit a pull request to provide...).
On Wed, May 1, 2013 at 9:13 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
The reasoning behind promises/futures is explained in more detail in my blog posts
A while back, I also wrote up an explanation of promises starting from base principles.
kriskowal/q/blob/master/design/README.js
Kris Kowal
There's also an extensive set of citations and links at the bottom of < strawman:concurrency#see>.
Thanks, the idea that .then() returns a new Promise is very very strange to me. What gets stored into that promise?
It seems as if those callbacks do not match the traditional DOM style event callback anymore, if their return value influences other operations. They're more like the function you pass to map(), and it's expected that the result of operation A goes in one end and something nebulous comes out the other... but I don't know how that second asynchronous operation even gets started. Is it assumed that the map()-style function returns a new promise, and then the extra promise .then() created is linked to it implicitly, ignoring the overhead? Based on my experience this implies a lot of bad things (for example, needing a trip through the event loop for every granular task) but I can see how it makes a lot of sense for the DOM if this is indeed the model.
The monad model is a great way to discuss this, actually: Future cancellation, as I understand it, is not a tri-state Maybe (Nothing | a | Cancelled); it is a dual-state maybe (Nothing | a), with a separate piece of state that represents the liveness of the future. In environments with deterministic garbage collection (like Python), you can actually represent cancellation via the liveness of a Future - I've used python futures libraries with no explicit cancellation method, where instead you cancelled a future by letting it get collected.
Obviously in a language like JS (and in C#, where I wrote my futures library and task scheduler) you cannot rely on garbage collection or liveness for cancellation, so the need for an explicit cancellation primitive arises. (One could argue that relying on GC for cancellation is a bad idea anyway, since it's easy to break).
Going to cc the lists on this since it seems like this was actually a valuable thread of discussion, my bad being conservative. (I can see now that Sam's PoV here is probably informed by nuances of existing specs like Promises/A that I am unfamiliar with because I have not used them extensively).
I think I see a lot of the historical confusion here as being rooted in the fact that the terms 'promise' and 'future' seem poorly-suited for describing a pipeline oriented primitive, if that's what these futures are. Maybe all discussion threads on futures need a big hairy disclaimer that tells people to read a description of what 'future' and 'promise' actually mean in this context :)