A Challenge Problem for Promise Designers (was: Re: Futures)
bruant.d at gmail.com
Fri Apr 26 03:19:28 PDT 2013
[adding public-script-coord and Anne]
Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
> On 26 April 2013 10:54, David Bruant <bruant.d at gmail.com> wrote:
>> 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
>> 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.
> The argument is for regularity. On a global scale, regularity helps
> the user, while exceptions, at best, are useful only locally -- an
> observation that, unfortunately, is difficult to demonstrate with toy
I see. To a large extent, it's also very hard to explain benefits to
refactoring. I gave an abstract example, Mark gave a more concrete small
example, but admittedly, none really capture the benefit I have
experience in a medium-sized Node.js application.
> In particular, irregularity and exceptions become a pain
> when you start building abstractions, or plug together abstractions.
> In other words, regularity is a prerequisite for what some people
> (including me) like to call "compositionality".
> Flattening for futures/promises is irregular because it means that
> certain behaviour reliably exists in all cases _except_ when the input
> is itself a future/promise. This may not seem like a big deal if you
> use them directly. But now imagine somebody built a bigger generic
> abstraction that uses futures/promises only internally. You find that
> abstraction useful, and for whatever reason, need to funnel in a value
> that happens to be a future.
This last sentence and especially the ambiguous "for whatever reason" is
the heart of the debate I believe. The idea expressed by Kevin Smith of
promises as featureless values is that there should be no reason for you
to funnel a value that happens to be a promise unless it's expected to
be a promise and not a non-promise value.
I have read somewhere (I can't remember where, hopefully MarkM will
confirm or say if I imagined it) that in E, if a variable contains a
promise and this promise is resolved, then the variable unwraps its
value and referencing to the variable suddenly means referencing to the
value. Promises are so deeply embedded in the language (syntax included)
that this unwrapping is seamless.
If I didn't imagine this, it'd be interesting if MarkM could expand on
that as it seems to imply that promises shouldn't be values but
lower-level than that.
Even if he confirms, it probably won't be possible to have something
More on the idea of "there should be no reason for you to funnel a value
that happens to be a promise", that's obviously unless you're building a
promise library or tools around promises.
One thing I have been convinced by your message is that it seems
necessary to provide the lowest-level non-flattening primitives so that
people build abstractions can that consider promises as values and will
want to know about nested promise types. It should be possible, but
building such abstractions doesn't seem like the 80% use case.
Based on my experience, I remain pretty strong on the fact that
flattening is a sensible default and really has practical advantages to
So, what about the following:
1) Providing lowest-level non-flattening primitives so that library
authors have fine-grained control and can build their own abstraction
where they can consider promises as values (what is missing in the
2) The API to be used by the average devs
(then/catch/done/every/any/etc.) has flattening semantics as this is
what people with the most experience have been advocating for (people
with a different experience are still free to speak up).
This API would just happen to be one possible library that can be built
on top of 1), but one library which semantics has proven to be useful
and popular among devs.
Would that satisfy everyone?
More information about the es-discuss