Inline (and this missed the list, BTW). On Thu, Sep 8, 2016, 17:18 Peter Seliger <[email protected]> wrote:
> 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 of those. 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 a subroutine. > 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` > case, as described by the OP, just would ignore that JavaScript might > 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 > ago. > See above. Also, I had very specific, optimization-related reasons due choosing syntax (the partial application proposals have usually used syntax, also). > The additionally provided link to an answer of mine at *stackoverflow* > might help backing up my above opinion. > - "sandwich pattern in javascript code" > > http://stackoverflow.com/questions/11371993/sandwich-pattern-in-javascript-code/27649488#27649488 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 <[email protected]> > wrote: > > 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: > https://www.npmjs.com/search?q=function+composition > > - 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 > avoid > > some of the [[Call]] boilerplate when called and when calling the > functions > > 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 > (avoid > > an extra function allocation), like with `f >=> x => console.log("x:" + > 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
