A Challenge Problem for Promise Designers (was: Re: Futures)

David Bruant 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
> standpoint.
The Priority of Constituencies [1] 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 [2] 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).

David

[1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
[2] https://mail.mozilla.org/pipermail/es-discuss/2013-April/030192.html


More information about the es-discuss mailing list