On Fri, Feb 24, 2017 at 6:35 PM, Šime Vidas <sime.vidas at gmail.com> wrote:

> Domenic's version using current `async`/`await` syntax is nice and clear
>> (one might tweak the variable names a bit to differentiate promises from
>> resolved values, but...).
>>
>
> This is the issue I have with this approach. The author is forced to
> create two sets of variables (for promises and resolved values), depending
> on the structure of the concurrent tasks. I think this is micromanagement.
>

Controlling the temporal mechanics of my functions seems pretty macro to
me. :-) We just appear to have different perspectives on it, which is fair
enough.


> Separately, I think you're going to run into implementational complexity.
>> [snip]
>>
>
> I’m not sure why it would need to be that complicated. [snip]
>

That would be simpler, yes, some kind of flag on the binding in the lexical
env object perhaps. It would also be a lot less powerful (though I suppose
if you need power, keep the promise). It seems like it would encourage
people to prefer large functions to small ones working together, though, so
they can avoid passing the hidden promise into/out of a call, triggering
the hidden `await`. Which, again, you could address by keeping the promise
and passing it around instead, but then that negates the utility you're
suggesting (not managing the process directly). And programmers don't need
more inducement to bad habits. (I'm particularly guilty of this particular
bad habit. But I'm trying...)

I'm also troubled by how this moves the exception point if the promise
rejects, from the nice clear `await` expression to when the side-effect of
use occurs. I suppose that's part of my overall concern about hidden
behaviors, though.

In case it’s not clear, this wouldn’t change how await works or be a
> replacement of it.
>

Just for the avoidance of doubt: You mean it wouldn't be `await`, but
something `await`-like but distinct, right? `autoawait`, `await*`,
`lateawait`, `jitawait`, something.

Again, I find it a really interesting idea, perhaps as a foundational
concept for a massively-async language. I'm just not sure about it for
JavaScript.

Anyway, those are my thoughts, FWIW. I'll lurk for a bit. :-)

-- T.J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170224/e231829c/attachment.html>

On Fri, Feb 24, 2017 at 6:35 PM, Šime Vidas <sime.vidas at gmail.com> wrote:

>> Domenic's version using current `async`/`await` syntax is nice and clear
>> (one might tweak the variable names a bit to differentiate promises from
>> resolved values, but...).
>>
>
> This is the issue I have with this approach. The author is forced to
> create two sets of variables (for promises and resolved values), depending
> on the structure of the concurrent tasks. I think this is micromanagement.
>

Controlling the temporal mechanics of my functions seems pretty macro to
me. :-) We just appear to have different perspectives on it, which is fair
enough.


>> Separately, I think you're going to run into implementational complexity.
>> [snip]
>>
>
> I’m not sure why it would need to be that complicated. [snip]
>

That would be simpler, yes, some kind of flag on the binding in the lexical
env object perhaps. It would also be a lot less powerful (though I suppose
if you need power, keep the promise). It seems like it would encourage
people to prefer large functions to small ones working together, though, so
they can avoid passing the hidden promise into/out of a call, triggering
the hidden `await`. Which, again, you could address by keeping the promise
and passing it around instead, but then that negates the utility you're
suggesting (not managing the process directly). And programmers don't need
more inducement to bad habits. (I'm particularly guilty of this particular
bad habit. But I'm trying...)

I'm also troubled by how this moves the exception point if the promise
rejects, from the nice clear `await` expression to when the side-effect of
use occurs. I suppose that's part of my overall concern about hidden
behaviors, though.

> In case it’s not clear, this wouldn’t change how await works or be a
> replacement of it.
>

Just for the avoidance of doubt: You mean it wouldn't be `await`, but
something `await`-like but distinct, right? `autoawait`, `await*`,
`lateawait`, `jitawait`, something.

Again, I find it a really interesting idea, perhaps as a foundational
concept for a massively-async language. I'm just not sure about it for
JavaScript.

Anyway, those are my thoughts, FWIW. I'll lurk for a bit. :-)

-- T.J.