Function composition syntax
isiahmeadows at gmail.com
Wed Sep 28 22:41:34 UTC 2016
Inline (and this missed the list, BTW).
On Thu, Sep 8, 2016, 17:18 Peter Seliger <peter.seliger at googlemail.com>
> Besides all the strong reasons that do support the argumentation for
> having a composition operator, one should take into account that there
> are more than this very special case of `compose`. *Function
> Composition* - or maybe *Method Modification*, as I would prefer
> referring to it - has already been done in a much wider variety e.g.
> with `before`, `after`, `around`, `afterThrowing` and `afterFinally`.
I hardly ever see these kinds of functions, and usually code them by hand,
anyways, to avoid the excess indirection. So I don't see the need for most
Also, I'm specifically targeting the narrow, common case here. I don't
think we need 10 infrequently used wrappers for a function, and they don't
belong in the prototype, either.
> They all do differ either in theirs arguments signatures and/or in the
> way of how the result of the first operation gets handled, due to what
> theirs specific goals are in how they do alter the control flow of a
> given function via another one.
Function composition is hardly a form of control flow beyond just executing
> The special case of currying needs to be mentioned as well, for
> `curry` does modify methods too.
I intentionally left currying out (as well as partial application) because
I wanted to see how this fared as a standalone addition. Arrow functions
already are concise enough to be useful.
> Introducing a composition operator just for the specific `compose`
> be rather in need for standardized implementations of
> `Function.prototype.before`, `Function.prototype.after`,
> `Function.prototype.compose`, `Function.prototype.around`,
> `Function.prototype.afterThrowing `, `Function.prototype.afterFinally`
> and even `Function.prototype.curry` … why not having them all, since
> `bind`, that also is a modifier, did make it into the standard years
See above. Also, I had very specific, optimization-related reasons due
choosing syntax (the partial application proposals have usually used
> The additionally provided link to an answer of mine at *stackoverflow*
> might help backing up my above opinion.
The sandwich pattern has little to do with composition, if any. I'm not
fully convinced you actually understand what function composition is.
> On Wed, Sep 7, 2016 at 4:10 PM, Isiah Meadows <isiahmeadows at gmail.com>
> > I would like to see a function composition operator make it into the
> > language. Currently, there is:
> > - Lodash: `_.flow` and `_.flowRight` (lodash/fp alias: `_.compose` and
> > `_.composeRight`)
> > - Underscore: `_.compose`
> > - Ramda: `R.compose`
> > - Tons of npm modules:
> > - Numerous manual implementations
> > Function composition could be far more efficiently implemented in the
> > engine, in ways not possible at the language level:
> > 1. They can create pipelines to optimize multiple composition chains
> > together.
> > 2. They can avoid most of the closure allocation cost internally.
> > 3. The returned functions can internally use a separate call path to
> > some of the [[Call]] boilerplate when called and when calling the
> > themselves (you don't need to verify twice).
> > Here's what I propose: a new infix operator `>=>` (operator and direction
> > can change) for composing two functions. It would do the following:
> > 1. Verify both operands are callable.
> > 2. Create a callable-only function that calls its left operand with the
> > original arguments and `this`, then calling its right operand with the
> > result and the same `this`.
> > 3. Sets its length to the left operand.
> > 4. Return the new function.
> > The reason I suggested an operator instead of a function:
> > 1. Fewer parentheses is always a plus.
> > 2. It allows engines to statically optimize functions in the middle
> > an extra function allocation), like with `f >=> x => console.log("x:" +
> > 3. It can simplify the internal model some to deal with a binary pair
> > instead of an array, especially when pipelining gets involved.
> > 4. Composition isn't usually combined as a function in JS.
> > What do you all think?
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss