Consider removing async function (was promise) integration

[JAForbes]

EDIT by proposer (TheNavigateur): I'm creating a shortcut to my current conclusion to explain the current closed status of this issue: #3 (comment) and an Explanation of the decision here in the proposal itself

Hi! Thank you for starting this proposal, composition means a lot to me and many others in the community. I hope this feature lands in Javascript, but I hope it lands right. Our language community has a tendency to add additional features to simple specs in the interest of convenience that in the long run actually become inconvenient because they are complex, harder to explain, and affect future proposals which tend to have backwards compatibility with them.

We see composition everywhere, having a built in operator will enable new patterns, it makes me very excited. But we often compose without knowing we're composing, and that can lead to unnecessary friction with library and pattern interop.

A few examples of composition hidden in plain sight in Javascript

• styled components are just composition
• decorators, are just composition
• jsx itself is composition of functions hidden behind syntax
• Promise chaining, is sort of composition
• method chaining generally, can be considered informal composition
• Array::map for example is definitely composition

We compose but we do it informally, and that informality leads to incompatibilities between interfaces without justification. It leads to "special casing".

If we keep compose as simple as possible, hopefully we can encourage the community to rally around that simplicity and receive emergent compatibility between libraries and specifications that were iterated on in complete isolation to eachother.

---

Composition is beautiful. It's extremely simple but enables so much power in that simplicity.

Promises are the exact opposite. The API is riddled with compromises, and these compromises continue to affect future proposals. One example being, Error handling behaviour of Observables being determined by Promises due to backwards compatibility.

I think there's some alternatives paths we could take to make interop with Promises more seamless without affecting the general simplicity of composition. (I'll write some code examples below) .

Alternatives:

1. In the future, after this operator lands, have a compose spec that data types can support and this operator will defer to.
2. Introduce a separate operator that is effectively f => x => x.then(f)
3. Take no language level action, because there's plenty of elegant userland solutions.

In the future, after this operator lands, have a compose spec that data types can support and this operator will defer to.

Data types can compose. That's what Promise.then sort of approximates after all. For example Array's can compose:

[1].map(f).map(g)

Observables can compose

stream$.map(f).map(g)

Iterators can compose (despite not having language level support yet)

function map * (f, it){
  for( let x of it ){
    yield f(x)
  }
}

// a lazy infinite sequence of squares that can be further composed
const squaredInfiniteRange = map( square, infiniteRange)

Composition is a general principle. Encoding specific support for Promises leads to a highly specific interpretation of composition that we'll constantly be appending to as we add new data types.

But what if we introduce a composition specification, similar to the iterator spec?

Promise.prototype[Symbol.compose] = function(f){
  return this.then(f)
}

Even though then isn't strictly composition, this solution at least allows other data types both in the language and in the community to interop with this new operator without language level coupling.

One confusing aspect of this proposal is, despite composition being general, we should not attempt to automatically compose different types together. E.g. Array's and Promises don't automatically compose with eachother, and they shouldn't. But this compose spec would make it trivial to make a mistake like that.

This problem is usually solved via transformers, but that is a finer point that specification proposal could tackle in it's own context.

Introduce a separate operator that is effectively f => x => x.then(f)

So if we want to compose promises, we can. We just need a util that can lift a function into the promises domain. then allows us to do that.

const then = f => x => x.then(f)
const f = a => Promise.resolve(a + 1)
const g = a => Promise.resolve(a + 2)
const h = a => Promise.resolve(a + 3)

f +> then(g) +> then(h)

If people find they want to compose async values with functions, this solves for that. If it becomes popular, maybe a static then function, or an operator that desugars to that function could be introduced into the language, leaving composition itself simple.

e.g. let's imagine there was an operator :x: that desguared to our then function (defined earlier)

f +> :g: +> :h:

As you can see, we can solve this problem using composition of specifications. Instead of bundling features into one big proposal. That's what composition itself teaches us to do.

Take no language level action, because there's plenty of elegant userland solutions.

I believe, if this proposal only supports functions, that's all we'll ever need. But I've hopefully demonstrated there's plenty of room for expanding on this spec in future versions if we find that isn't the case. I'd really like to give this specification some room to breathe, to be used in real projects and to encourage new practices to flourish in the community. I think this proposal could completely change how we think about and write Javascript, so there's a lot of reason to get this proposal right.

The previous solution is completely definable in userland. It's like adding ingredients when cooking, we can always add to the mix but we can't take away (so be especially careful when adding).

---

If there's one thing I want JS to get right, its composition. Its so powerful, so generic, so simple.

I implore you, and the community - for this language level formalization, let's keep it as simple as possible.

Thank you for your time.

[evilsoft]

I also agree that Promises should NOT compose like functions compose.
While they can be composed, as @JAForbes mentions, the way they compose is very different and would require Kleisli composition (around the then syntax) composing functions of the form a -> Promise b e. Which of course does not really need to return a Promise due to how the .then chain works.

So while the weakness (as some might say) of not requiring the form a -> Promise b e would seem like they are the same functions through a typical pipe, they are in fact very different. It is my opinion to not muddy the waters even more then we have with how we interact with Promises.

Now that said, I can see the argument of well that is the way they work now, lets just roll with it. But I say that platform is wrought with nothing but hard to maintain flows that will make it hard to refactor from Eager Promises to more the more Lazy, Declarative Types, when the need arises.

Just my 2 cents on the subject.

EDIT:
Oh and 👍 to the separate operator.
Could be easily expanded on to do binds on Promises, Iterators , Streams and Arrays.
Anything that can effectively implement the chain spec in fantasy-land.

[davidchambers]

Promises are complex, unprincipled, and easy to misuse. Every language feature which treats promises specially is complex and unprincipled as a result.

I would like those developing future ECMAScript releases to stop adding special cases for promises. If one day these people come to agree with me that promises (as specified) were a mistake, I very much hope promises will not yet be irreversibly entwined in numerous language features.

[achung89]

Would not go as far as to say that promises are a mistake, but I agree that adding complexity to the operator without proper syntax cues could lead to confusion.

On solution is just to allow for use with await

let pipe = await p1 +> fn1+> await p2 +> fn2

That would make it so that it is scoped only to async functions, which limits the complexity

[keithamus]

Promises are a useful primitive that have the minimal set to allow them to be swallowed up by await syntax. Thinking of them beyond the scope of await could be a mistake.

But even regardless of Promises, I think this proposal - strategically - should wait to see what becomes of the pipeline proposal; I'm sure people will argue semantics but they are one in the same.

If this proposal bides its time, waits for the pipeline operator proposal to solve these issues (of which there are discussions around), then come in off the back of that, it seems to me (admittedly inexperienced) that this will have far more traction if it aligns to the pipeline proposal. The corollary of this is that the effort in this discussion should probably move there - tc39/proposal-pipeline-operator#31, tc39/proposal-pipeline-operator#53, tc39/proposal-pipeline-operator#56 are all open discussions around this.

[TheNavigateur]

The original intent was not to allow promises as such, but async functions, which are functions after all.

I have updated the proposal to say so instead. Hopefully this satisfies everybody, or have I missed the point?

async functions are now in the language, so I would suggest that supporting async functions in function composition is actually necessary for any such proposal.

Understand that none of the proposals in these comments seem to have fully addressed the following use case, where an asynchronous function is required as the result of a composition:

const getDistanceInLocalUnitsAsync = getDistanceInStandardUnitsAsync +> localizeDistance
//
const distanceInLocalUnits = await getDistanceInLocalUnitsAsync(myRoute);

@JAForbes Will your :f: proposal evaluate to an asynchronous function, or a synchronous one? It needs to be an asynchronous one... so if it does, can you talk me through in more detail how this would be set up, for the given use case above?

@achung89 await f() is used to evaluate the result of the asynchronous function, so await f would seem like a questionable use of the await keyword for this...

[achung89]

sorry I misunderstood, I thought the operators was to compose promises not async functions.

You are right, await is a run time evaluation, it might add to the confusion to use that in composition

Even for async fns, I think we should have a different syntax for the same reasons, to make it easier to distinguish between a resolution of a promise vs. the resolution of a fn. (and to reduce ambiguity between a composition that runs synchronously and a composition that runs asynchronously) but that might be just my opinion

[joshburgess]

@keithamus Composition (compose operator) and application (apply aka pipe operator) aren't one in the same. Personally, if I could have only one, I'd rather have the compose operator... but I'd like to see both in the language.

I'd also like to see both right-to-left and left-to-right variants of each.

[skatcat31]

Take no language level action, because there's plenty of elegant userland solutions - James Forbes

@JAForbes I'm adding that to my wall of quotes. I like this on a deep personal level.

As for the chosen operator, I have a problem with it being very noisy with arrow functions:

const missyElliot = reverseBits +> v => -1 * v +> v => v--;

// versus

const missyElliot = compose( reverseBits, v => -1 * v, v => v--);

That first one is noisy, confusing, and hard to make out with lambdas, and leads to more typing the more functions you introduce( assuming single character names: line length == # of functions * 3 versus line length == # of functions * 2 + 9). The operator version also leads to confusion of order of operations. Am I doing the left first, than the right like every other use of feed > prior art?

I'm all for leaving this in user land or just a function. Heck it's pretty easy to do on a single line too

// Right to left
const compose = (...fns) => (...values) => fns.reverse().reduce( (v,fn,i) => i === 0 ? fn(...v) : fn(v), values )

// Left to Right, sometimes called pipe or pipeThrough
const compose = (...fns) => (...values) => fns.reduce( (v,fn,i) => i === 0 ? fn(...v) : fn(v), values )

[JAForbes]

@TheNavigateur Ah I think I didn't explain this clearly enough, the above proposals do cover that case, in fact that's what I was assuming you meant originally.

But I imagine you're thinking I'm suggesting wrapping async functions in some decorator or syntax, but I'm instead suggesting to decorate subsequent functions in the composition after an async function is introduced.

That's a mouthful so here's some working code: https://repl.it/MCsF/1

I'll also explain here in case that link ever dies.

If you've got 2 functions, f and g, and f is async you'd compose them like so:

f +> :g: 

Or in vanilla JS:

const then = (fn) => (promise) => promise.then(fn)

compose(then(g), f)
// or
pipe( f, then(g) )

Just like, if a function returned an array, we might want to map over it in subsequent functions:

const f = () => [1,2,3]

const g = x => x * x

pipe( f, map(g) ) //=> [1,4,9]
// f +> :g:

The symbol.compose interface would allow different types to determine what +> does on a particular type, so both proposals would handle the case you are concerned about - because +> would just defer to the compose method on the type which would do as above.

async functions are now in the language,

async functions are in the language. But what does that mean? What is an async function from the perspective of composition?

All async functions are from the perspective of composition, is a function that returns a Promise.

At first it seems simpler to special case async functions. But what about generator functions? What about functions that return any type under the sun, maybe a function that returns an observable will need a special case too?

And there's a lot more types that the JS community isn't considering yet, but one day they will be interested in them and we'll want to add them to the language and special case them as well.

Composing functions that return promises should be no different to composing functions that return arrays. I know that probably sounds ridiculous when you first hear that, but its absolutely true. There's nothing special about async functions from the perspective of composition.

I absolutely understand the sentiment, I used to think much in line with you. But composition itself tells us to build up complex functionality by combining smaller simpler component parts. Having a compose operator that automatically handles promises, observables, generators and so on - goes against the very spirit of composition.

---

One more aside.

That :x: syntax need not be promise specific either. What were doing there is a more general principle as well, we're lifting a function into a particular context (in this case Promises).

I'm not proposing we add such syntax. But by not special casing particular types we leave the door open for Javascript to organically grow to support new and powerful ideas, by special casing we effectively weld Javascript to programming patterns of the past eternally. That's a general principle that applies to all language proposals. The proposals themselves should be composeable.

If any of these examples still aren't making sense, I apologise, I really do understand what your goals are and they are admirable, I hope I can convince you that we can meet all those goals while also keeping compose super simple.

If you want to go through it 1 on 1, I think my gitter url would be... https://gitter.im/JAForbes

If this was previously making no sense and I convinced you, please consider spreading this idea to other proposals that suggest we need to special case particular data types.

[TheNavigateur]

Promises are gone from the proposal. It was just a logical mistake on my part in relation to async functions. Unless someone objects to async functions being supported as described in the proposal (where the expression evaluates to an async function if one or more of the operands is an async function), I will mark this issue as closed (resolved), leaving about 2 weeks (approx) for any such objections to be initiated, upon which I will either keep this open or recommend moving to a new issue. Sorry for the mistake in the original proposal talking about Promises - I really had meant async functions all along. I had written "Promise (asynchronous function)" thinking that promises are the generic type for async functions, and so supporting them would automatically support async functions plus other cases of the generic type where required, but of course this is wrong - they are not in the same family. An async function returns a promise, it is not itself a promise.

[JAForbes]

FTR I am objecting to async functions. Everything I've written so far has been about async functions. Kind of surprised that hasn't been understood.

[TheNavigateur]

@JAForbes Then could you make a new issue? Promise and async function are different types not hierarchically related, since promises are not functions, and async functions are necessarily functions, and are not themselves promises (but that just happen to return a promise when executed). I've made a significant change on the basis of this issue (removed my illogical use of Promise in the context of my intention to allow async functions as a composition operand). Removing support for async functions themselves, in the way proposed, would be a significant other step.

What error would you show if an async function is used as an operand? "Async functions are not supported in function composition"?

I would defend the support for async functions in a function composition chain on the basis of simplifying async programming with composition, while not clashing in any way with ordinary synchronous composition, but rather complementing it.

[JAForbes]

I've made a significant change on the basis of this issue

Thank you for doing that, its appreciated.

What error would you show if an async function is used as an operand? "Async functions are not supported in function composition"?

You wouldn't throw an error at all - that's valid composition. I think I've shown already that you can compose async functions just fine without actually special casing them in the compose operator. You just need to lift subsequent functions in the composition to the promise context (using the then function I demoed), in the same way you'd need to do traverse any other data type (like the map example I gave for arrays).

Passing a promise into a function is absolutely fine, and in many cases we wouldn't want to automatically build a promise chain for the caller. Its better they are explicit. And it's better the compose operator doesn't treat different data in different ways, it's better for it to not infer intent.

That kind of api design has a place, but at the very edges of a system. Doing it at the language level is limiting. It harms composition.

I would defend the support for async functions in a function composition chain on the basis of simplifying async programming with composition

Are you familiar with Rich Hickey's distinction between simple and easy? Really good stuff, it had a huge impact on the JS FP community, it informs almost every library and interface decision in the community. If not, I recommend checking it out, it may explain the opposition to promises in this proposal - without that perspective it may seem illogical.

I'll paraphrase: Having the composition operator be promise aware is additional functionality and semantics which is by definition more complex. It may seem easier but it's not simpler. It increases the dimensions of the possibility space. It increases the API surface area. And composition, generally, relies on the exact opposite of that.

And out of all the specs where we should pay close attention to the simple vs easy distinction: is composition. Composition is all about extremely simple units that are simple to combine with other simple units. It allows us to build complex functionality by piecing together small simple parts.

Making any one part "convenient" is a local optimization that seems better in the near term but it complicates that unit, it makes it hard to compose, it introduces edge cases. Whenever we do make these concessions, it has to be justified, in this case it isn't.

There's actually a separate type of composition that @evilsoft covered earlier, that is far closer to what you are proposing, it's called Kleisli composition. But - we can build Kleisli composition on top of normal function composition. We can't do that, if function composition in JS has special case behaviour for Promises.

And I'm definitely not saying we can't compose async functions, I'm saying we ignore the fact they are async. Ad we rely on a separate function or operation to build that promise chain for us (if that's what we want to do).

That's what my counter examples were demonstrating. E.g. check out the repl.it link from earlier, I'm composing async functions there, but compose itself has no awareness that the functions are async. It's simpler than that, all it does is connect inputs to outputs, and that's very powerful.

[TheNavigateur]

Can you create a new issue for this? I'm closing this issue in relation to Promises integration as it is not in the proposal.

If you could include your alternative solution to composing asyncFunction1 +> syncFunction1 +> asyncFunction2 +> syncFunction2 into an async function that passes the return value from each into the next (not the promise, the actual return value in the case of the async functions), it would be great.