Observable/Promise parallel control flow proposal

# Isiah Meadows (4 years ago)

See: gist.github.com/isiahmeadows/ba298c7de6bbf1c36448f718be6a762b

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.


Isiah Meadows me at isiahmeadows.com

# Matthew Robb (4 years ago)

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
# Isiah Meadows (4 years ago)

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

# Matthew Robb (4 years ago)

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
# Jordan Harband (4 years ago)
  • 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.
# Isiah Meadows (4 years ago)

I presented it as a holistic concept, but I ensured it still could be added piecemeal. When I have time, I'll add that to my gist, how it can be taken and implemented piecemeal.