Ordering of parallel `chain`s

[Twisol]

Sourcing from a when.js issue:

p.chain(f).chain(g);
p.chain(h);

In the presence of side-effects, the order of execution matters. If the order is FHG (i.e. breadth-first), and h has a side-effect, then g may be affected by a totally separate chain (and indeed, p.chain(h) could be in an entirely different part of the file).

We could stick with precedent and push the concern downstream, but I want to at least raise the issue as something that should be considered somewhere along the line.

[jneen]

Is .chain mutating p in your example? It seems like when.js is actually launching IO operations when .then is called, which is not really part of the spec. A truly monadic promise would just return another promise, and you'd have to call .run() or something on your application to actually launch it.

[SimonRichardson]

Agreed, we should make a note in the spec that performing IO operations with in a chain should return another promise, or it's up to the user to manage.

[bergus]

In promises-aplus it was figured out that the order of g and h is unspecified - which especially makes sense if f is asynchronous so that it runs concurrently. Assuming the functions are pure it doesn't make a difference anyway, and in case they have side-effects and somehow depend on each other their order should be stated explicitly in the code if that is required.

[SimonRichardson]

Each function should ideally be referential transparent and with lack of side effects. So I'm closing this as a part of the unspecified part of the specification.

Reopen if you disagree :8ball:

[puffnfresh]

@SimonRichardson :+1: