Native Function Composition

# Simon Staton (a year ago)

I'm not sure if this has been proposed before, if not I would like to propose a native way to handle function composition.

This is not that trivial, it can be achieved via a generic utility however considering this is quite a common pattern it might make sense to include it as a native feature set

Something along the lines of

Function.prototype.compose(); // chained at end of callstack

Function.prototype.composeBefore();

This could* A) return a new function B) *chain from the original reference

Quite often composition is not limited to a single function so it could be a better approach to allow multiple arguments to be chained

Could also follow a similar design as the Java implementation docs.oracle.com/javase/8/docs/api/java/util/function/Function.html#compose-java.util.function.Function-

, Simon Staton

# dante federici (a year ago)

This is probably covered by the pipeline operator proposal:

tc39/proposal-pipeline-operator

# Naveen Chawla (a year ago)

That's a syntax for calling functions, not creating a composed function for being called any time.

Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>.

However, if it were used for function composition instead, it could be more useful e.g.

Current way:

const doubleThenSquareRoot = value=>squareRoot(double(value))

Pipe:

const doubleThenSquareRoot = double |> squareRoot
# Claude Pache (a year ago)

Le 24 août 2017 à 23:13, Naveen Chawla <naveen.chwl at gmail.com> a écrit :

That's a syntax for calling functions, not creating a composed function for being called any time.

Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>.

Straightening the order is still a big deal in lengthy expressions. And imbalance of nesting parentheses is one of my main sources of syntax errors.

# Simon Staton (a year ago)

I have started to setup a proposal for this, contribution and changes are greatly welcomed. So far I have looked at 2 approaches, one more functional and the other is using infix operators.

simonstaton/tc39-functional-composition-proposal, simonstaton/tc39-functional-composition-proposal

I have included these points you have raised regarding the pipeline operator and looked at alternatives.

At some point today I will include more details on this. Feel free to open PR's

# Naveen Chawla (a year ago)

On Fri, 25 Aug 2017 at 12:24 Claude Pache <claude.pache at gmail.com> wrote:

Le 24 août 2017 à 23:13, Naveen Chawla <naveen.chwl at gmail.com> a écrit :

That's a syntax for calling functions, not creating a composed function for being called any time.

Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>.

Straightening the order is still a big deal in lengthy expressions. And imbalance of nesting parentheses is one of my main sources of syntax errors.

Yes I think this applies in cases of function composition. My point was that it doesn't save much code, especially in comparison to allowing |>

to be used directly as a function composition operator, which would give you the linearity you could want, as well as adding a whole dimension of expressive power to the language, instead of just allowing a re-ordered way of writing existing syntax.

# Naveen Chawla (a year ago)

Aw, snap! I've written up a much shorter proposal myself. I do think composition should be in-order of call, i.e.

const composed = a |> b |> c  //c(b(a(f)))

Reads "do a then b then c"

The advantage is that no-param calls can also be easily chained using the syntax:

const switchOnTheEngineThenDrive = switchOnTheEngine |> drive

I also don't think the reverse operator should be allowed. I think it compromises readability and could introduce confusion.

I've written my shorter proposal here: TheNavigateur/proposal-pipeline-operator-for-function-composition

# Simon Staton (a year ago)

That link appears to be broken Naveen, If you are considering a similar approach let’s collaborate would be interested to get your outlook on this and we could probably expand on either of these

# kai zhu (a year ago)

-1

composition and pipeline-operators are both INCOMPATIBLE with javascript's async-programming style, and will likely result in tech-debt when used. its fairly common for blocking-code to evolve into async-code as features are added, e.g.

result = arg |> operator1 |> operator2 |> operator3;

// becomes spaghetti-code when operator2 evolves
// to require async-merging with database-queries, file-reads, etc.

...
operatorAsync2(arg |> operator1, function (error, data) {
    if (error) {
        ...
        return
    }
    result = data |> operator3;
    ...
});

# Jordan Harband (a year ago)

"incompatible" is a very strong and likely incorrect claim. `(sync1 |>

sync2 |> async1).then(x => x |> sync3 |> async2).then(x => async3)` could

work just fine.

# T.J. Crowder (a year ago)

On Sat, Aug 26, 2017 at 3:07 AM, Jordan Harband <ljharb at gmail.com> wrote:

"incompatible" is a very strong and likely incorrect claim. `(sync1 |>

sync2 |> async1).then(x => x |> sync3 |> async2).then(x => async3)` could

work just fine.

Or indeed, a robust proposal might allow for async functions in the pipeline (with some indication, so you can look at the code and reason about it; although then accepts non-thenable values and you can't tell by looking, so...). Conceptually:

let x = sync1 |> sync2 |*> async1 |> sync3 |*> async2 |*> async3;

-- T.J. Crowder

# Naveen Chawla (a year ago)

I've updated my proposal to use +> instead of |>, based on this discussion:

tc39/proposal-pipeline-operator#50

TheNavigateur/proposal-pipeline-operator-for-function-composition

# Isiah Meadows (a year ago)

Just thought I'd throw this out there: I've been off-and-on working on my own function composition strawman 1 for about a year now 2. I decided just now to make some edits to clean up the proposal and address some other ideas that have come up since (e.g. async composition).


Isiah Meadows me at isiahmeadows.com

Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com