Native Function Composition
This is probably covered by the pipeline operator proposal:
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
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.
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
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.
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
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
-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;
...
});
"incompatible" is a very strong and likely incorrect claim. `(sync1 |>
sync2 |> async1).then(x => x |> sync3 |> async2).then(x => async3)` could
work just fine.
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
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
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
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