Observable/Promise parallel control flow proposal

Jordan Harband ljharb at gmail.com
Tue Mar 7 17:45:21 UTC 2017


* It was dropped for a number of reasons, including confusion with `yield
*`, and there being no way to provide syntactic support for Promise.race,
or other future combinators.

On Tue, Mar 7, 2017 at 4:18 AM, Matthew Robb <matthewwrobb at gmail.com> wrote:

> One major difference I can see is that the earliest async/await proposals
> included `async *` which was eventually dropped for no practical reason
> other than it seemed to add bloat to a spec that AT THE TIME looked like it
> would be hard to push through the process. History tells a different story
> for async/await and it may be better that it was actually left out
> initially it's hard to say. What I can say is the use case has been a part
> of the discussion from the very beginning for awaiting a list of things.
>
> There really are two phases to your spec. A subset that can apply
> immediately to the existing promise-based abstraction and a larger
> extension of that which could apply to a wider range of async models such
> as Observable. I think both are well represented but it would be helpful to
> see them explicitly broken down into those two distinct sets.
>
>
> - Matthew Robb
>
> On Tue, Mar 7, 2017 at 7:03 AM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> I'll note that async functions had a similar thing going on, too. Most
>> third-party libraries had most issues taken care of, but what landed
>> in the spec was only a fraction of what most libraries provided. The
>> Observable proposal is turning out to be similar in this respect.
>> -----
>>
>> Isiah Meadows
>> me at isiahmeadows.com
>>
>>
>> On Tue, Mar 7, 2017 at 6:23 AM, Matthew Robb <matthewwrobb at gmail.com>
>> wrote:
>> > Isiah I think there is a lot of value in the work you have done here. I
>> > think it would be useful to see this broken down in a way that makes
>> solving
>> > the Promise cases in a way that would be forward compatible with
>> Observers
>> > front and center. Right now it feels optimistically speculative because
>> the
>> > approach is treating Promise and Observable as equal edges to the
>> problem
>> > which may be true but today we have under facilitated Promise
>> abstractions
>> > and no one is feeling any pain/loss around missing Observable support
>> (yet).
>> >
>> > Does any of that make sense?
>> >
>> >
>> > - Matthew Robb
>> >
>> > On Sun, Mar 5, 2017 at 8:24 AM, Isiah Meadows <isiahmeadows at gmail.com>
>> > wrote:
>> >>
>> >> See: https://gist.github.com/isiahmeadows/ba298c7de6bbf1c36448f71
>> 8be6a762b
>> >>
>> >> TL;DR: I've created a proposal to enable modelling of parallelism and
>> >> non-linear control flow, to interoperate with the non-determinism of
>> >> Promises and Observables. I drew inspiration from non-von Neumann
>> >> paradigms in creating the primitive operations. I'm seeking feedback
>> >> for potential improvements and just overall feelings on the idea.
>> >>
>> >> Obviously, this is blocked on the Observable proposal [1] getting
>> >> completed, and may need edited accordingly. And I've already proposed
>> >> a similar thing [2] in their repo, but not quite to this scale.
>> >>
>> >> [1]: https://github.com/tc39/proposal-observable
>> >> [2]: https://github.com/tc39/proposal-observable/issues/141
>> >>
>> >> -----
>> >>
>> >> Isiah Meadows
>> >> me at isiahmeadows.com
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170307/551f2836/attachment-0001.html>


More information about the es-discuss mailing list