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

[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@gmail.com> wrote:
>>
>> 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.
>
> 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
> examples.
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 
that embedded in JavaScript, but I think it's an interesting perspective.


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 
large-scale development.

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 
current API?)
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?

David

Received on Friday, 26 April 2013 10:19:58 UTC