Do futures represent a pipeline? (was Re: Future cancellation)

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 :)

-kg


On Tue, Apr 30, 2013 at 12:41 PM, Sam L'ecuyer <sam@cateches.is> wrote:

> Hey Kevin,
>
> I'm not aware of any specific doc that calls promises pipelines.  That's
> an abstraction of then().  Given a Future, it's not possible to access its
> value without registering a success callback.  You have to pass a function
> with then(), which in turn returns a new Future based on whatever function
> you passed in.
>
> eg:
>
>     var ajaxWork = doAjaxWorkAndReturnFuture(url);
>
> You can never do `ajaxWork.getValue()`
> You could use
>
>     var handlingData = ajaxWork.then(handleData, handleError);
>
> But similarly, handlingData is a promise.  You can't get a value without
> then().
>
> If you invoked ajaxWork.cancel(), what would happen to handlingData?  It's
> downstream and is eventually expecting either a value or an error.  Would
> it just get ignored?  What about the Futures that are expecting data from
> handlingData?  Maybe handlingData got passed as a parameter to another
> function and has a chain of 100 then()s?
>
> I certainly understand the value of cancellations in deferred computing,
> but it doesn't fit the promise model any more than the Maybe monad should
> be Nothing or Just(a) or Cancelled.
>
> Maybe that was coherent.  Let me know if it wasn't :)
>
> -sam
>
> -----Original Message-----
> From: "Kevin Gadd" <kevin.gadd@gmail.com>
> Sent: Tuesday, April 30, 2013 3:14pm
> To: "Sam L'ecuyer" <sam@cateches.is>
> Subject: Re: Future cancellation
>
> Can you point me to the definition of Future you are using here? It is not
> one I have ever encountered; the idea of some sort of pipeline is to my
> understanding actually separate from what a future/promise actually is.
>
> http://en.wikipedia.org/wiki/Futures_and_promises certainly does not
> suggest that a future is much more than a 'value that may be available
> sometime in the future'.
>
> Replying off-list because I am not sure if I missed some past discussion?
>
> Pipelining seems valuable, certainly, but it is not so obviously a part of
> futures/promises to me that it is worth throwing cancellation out in order
> to get pipelining. Especially because it is (to me at least) questionable
> whether pipelining is a future feature, when it seems more like a task
> scheduler or language feature.
>
> -kg
>
>
> On Tue, Apr 30, 2013 at 12:11 PM, Sam L'ecuyer <sam@cateches.is> wrote:
>
> >
> > > I don't know what the right shape for a cancellation API is,  but one
> > > should not assume that this problem is inherent to cancellation. I
> don't
> > > think it is.
> >
> > Take my input with a grain of salt, but I think it is.
> >
> > Futures form a cascading pipeline (a series of tubes, if you will) that
> it
> > promises to follow, either succeeding or failing but always continuing.
> >  Cancellation doesn't fit that model, because it involves either
> > destructively reshaping the pipeline after it's started or trying to
> shove
> > events in the wrong direction.  If a value is no longer needed and you
> know
> > ahead of time that it may not be, then a) keep the resolver and reject
> > (reject() takes a value.  Use it.), or b) put an `if` in the success
> > callback.
> >
> > -sam
> >
> >
> >
> >
> >
>
>
>