Composing Compositional Functions

[benjamingr]

No pun intended.

In the issue about use cases here we were wondering how compositional functions... compose.

If we have an async composer and a cached composer (memoizing) doing async cached and cached async would mean two different things. I can't figure out if the use case of composing compositional functions that'd need the await hook is something we can or should do.

How should await be handled in cases like observable async foo(){? Should the syntax even be allowed? If not, should we provide a compose function (or similar) that'd delegate between compositions?

[jhusain]

in a perfect world that there would be exactly the number of composition functions that there are asynchronous primitives. The composition function is intended to be the auto-flattening mondic bind for a scalar async type. Under the circumstances I feel as though allowing composition functions to be composed would promote anti-patterns in which composition functions are used for things that decorators should be used for.

[benjamingr]

If all this proposal aims to solve (and I think it can solve more) is await for async primitives other than promises - you probably wait to explain why exposing a then on the primitive's prototype or adding a single symbol for a then hook wouldn't suffice in the proposal

[jhusain]

That's a completely reasonable approach. Unfortunately it does not cover the following case:

async function(){
return 1;
}

A developer may simply decide that they want to build a function which is asynchronous, and then later on compose it together using other asynchronous primitives. It is not necessarily a good experience to force the appearance of an await statement A developer may simply decide that they want to build a function which is asynchronous, and then later on make compose it together using other asynchronous primitives. It is not necessarily a good experience to force the appearance of an await statement.

[jhusain]

FYI, I will bring your then idea up as an alternate proposal. In all likelihood we would use a symbol, but the general idea would be the same.

[benjamingr]

It is not necessarily a good experience to force the appearance of an await statement

I assume this is a response to "why decorators when we can solve more". I agree that forcing await would be silly and I definitely think

async function get(){
    return 1;
}

Should work no matter what proposal ES ends up getting (like in C#). I'm just saying that the potential for language betterment here is huge if we can work out the semantics here.

your then idea

Thanks, I'd appreciate it.

To clarify: I think it should be explained in the proposal itself (pros and cons vs hooking on then)

[bmeck]

since the decoration is static and async is a fn, you could always perform wrapping:

let memoized_async = memoize(async);
memoized_async function foo() {
}

not the prettiest, but practical

[benjamingr]

This proposal was a really good idea in retrospec - shame nothing happened with it :(