A Challenge Problem for Promise Designers (was: Re: Futures)
bruant.d at gmail.com
Fri Apr 26 01:54:04 PDT 2013
Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
> On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble <tribble at e-dean.com> wrote:
>> So what's an example
>> that motivates you to want to build a tower of promise types? The main one
>> I know of is the implementation (not use of) higher-order collection
>> constructs that use promises internally (e.g., the implementation of map and
>> reduce for an async, batching, flow-controlled stream of Promise<T>). That
>> kind of rare example can have more advanced hooks (like Q).
> I think it's more important to see examples of why you want to
> *flatten* them automatically. Having "towers of promises" keeps us
> consistent with Futures-as-monads, which is useful from a theoreticaly
The Priority of Constituencies  asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helping users? authors (more than what I described at  which is
derived from my own experience)? implementors? specifiers?
I'm not saying the theoretical benefits don't exist, but I'd like to see
how they translate in concretely improving my life as a developer using
promises. I've explained the benefits I see for flattening from the dev
point of view, I'd like to see the equivalent.
> This is similar, from an algebraic standpoint, to
> allowing arrays of arrays, or sets of sets, or any other monadic
> context doubled up.
Arrays of arrays make sense as a data structure. Promise of promise does
*in theory*, but as Kevin Smith said, in practice, promises are
featureless values; the only thing you care about is that an operation
is async and the actual non-promise eventual value that you'll get.
Given this practical use of promises, why bother with Future<Future<T>>?
I don't mind if they exist, but as a developer, I'd like
Future<Future<T>> to be hidden so that I don't have to deal with them. I
want all APIs I interact with to make me interact with promises and
non-promises values and that's it. I don't care about the rest. Hide
Future<Future<T>> under the carpet, please.
If super-experts want to play with Future<Future<T>>, give them, but
don't make that the default way to interact with promises. (as a side
note, Mark Miller and Domenic Denicola are some of the most experts I
know and they're also asking for flattening. It sounds strong enough of
a signal for me to give on non-flattening; if they had any use, they
would have expressed it).
More information about the es-discuss