Function composition syntax

Isiah Meadows 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>
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 <isiahmeadows at gmail.com>
> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160928/8873f4e5/attachment.html>


More information about the es-discuss mailing list