Converge via array in pipe/compose

[dalgard]

It would be really convenient if pipe and compose accepted an array for an argument, so that these would all become equivalent:

R.pipe(f, [g, h], i)(x)
R.compose(i, [g, h], f)(x)
R.compose(R.converge(i, [g, h]), f)(x)
i(g(f(x)), h(f(x)))

It would give a slightly weird impression if the signature of pipe/compose had been different, with the supplied functions wrapped in an array (#1644), because the outer array would then not have the same meaning as the inner array. But since this is not the case, I think this syntax is nice.

[CrossEye]

This is absolutely fascinating! It combines, say, pipe and converge fairly seamlessly with an intuitive syntax.

It will take me some time to think through the implications, but it would be another great way to get rid of converge. I really want to find some extension of this that would also handle useWith. I don't know what that is, but it does feel as though it might be possible.

(Don't you think that the order of elements inside the array in compose should be reversed?)

[davidchambers]

This is an interesting idea. I'm pretty sure I don't want to see R.compose and R.pipe support this: they already have awful type signatures! I'm open to the possibility of a new function which makes "diamond-shaped" compositions easier to define.

[CrossEye]

Perhaps flow as kindred to pipe. And if we did create a new function, we wouldn't have to define both directions as with compose.

If there is an intuitive way to cover useWith as well, I would find this a really big win.

[scott-christopher]

This feels somewhat related to the notion of Arrows, with tuples being swapped with arrays.

https://en.wikibooks.org/wiki/Haskell/Understanding_arrows#An_Arrow_can_multitask

If we specialise the Arrow typeclass to functions, we get something that looks like:

first  :: (a -> b) -> (a, c) -> (b, c)
second :: (a -> b) -> (c, a) -> (c, b)
(***)  :: (a -> c) -> (b -> d) -> (a, b) -> (c, d)
(&&&)  :: (a -> b) -> (a -> c) -> a -> (b, c)

And swapping the tuples out with lists could get something like:

first  :: (a -> a') -> [a, b, ..., z] -> [a', b, ..., z]
second :: (b -> b') -> [a, b, ..., z] -> [a, b', ..., z]
(***)  :: [(a -> a'), (b -> b'), ..., (z -> z')] -> [a, b, ..., z] -> [a', b', ..., z']
(&&&)  :: [(a -> b), (a -> c), ..., (a -> z)] -> a -> [b, c, ..., z]

first and second here are affectively just adjust(_, 0) and adjust(_, 1) respectively, while *** and &&& become close to representing useWith and converge respectively.

It should then be possible to replicate the existing converge and useWith functions: ^[1]

converge = (mergeFn, fns) => compose(unapply(mergeFn), starStarStar(fns));
useWith = (mergeFn, fns) => compose(unapply(mergeFn), andAndAnd(fns));

Getting back to the original request here, something like this should then be possible:

pipe(f, andAndAnd([g, h]), unapply(i))(x)
compose(unapply(i), andAndAnd([g, h]), f)(x)

While this doesn't have the same brevity as just dropping an array of functions in a compose chain like the original suggestion, I wonder whether something could potentially be gained here.

---

^[1] Feel free to come up with better names for andAndAnd and starStarStar

[CrossEye]

While this doesn't have the same brevity as just dropping an array of functions in a compose chain like the original suggestion, I wonder whether something could potentially be gained here.

At the very least, there's something to be learned by investigating this.

I might still play around with the original proposal, as this might really help build declarative pipelines, a worthy goal. I wish I could think of a good extension to this for useWith. The only one that's coming to mind is flow([[pick, identity]], map), and even if that wasn't starting to lose the readability of the original, I'm afraid that it might introduce some ambiguity.

[benperez]

@scott-christopher Nice! I'd love to see &&& and *** in ramda. I think I've seen &&& called fanout. A good name for *** might be flow since the inputs flow through to the arrows (functions)

I personally prefer these versions since they aren't variadic:

first  :: (a -> b) -> (a, c) -> (b, c)
second :: (a -> b) -> (c, a) -> (c, b)
(***)  :: (a -> c) -> (b -> d) -> (a, b) -> (c, d)
(&&&)  :: (a -> b) -> (a -> c) -> a -> (b, c)

[dalgard]

@CrossEye: I don't think the order should be reversed in compose, since it is a reflection of the parameter order, not the application order.

I like the name flow (the way @CrossEye suggests). It is better than pipe, in my opinion, since pipe in various other contexts means direct invocation rather than composition.

I'm surprised that no one has expressed any concerns about the signature, though. As much as I like these kinds of APIs, wouldn't it be considered overloading?

The stuff about Arrows is too advanced for me at this stage.

In regard to useWith, its use clashes with the fact that functions only return a single value – useWith can only ever be used as the first function in the pipe (without resorting to destructuring), whereas converge can be placed anywhere I guess it could be placed either as the first function or after a converge. Hmmm...

@CrossEye: The double array syntax is a bit too esoteric, I think.

@davidchambers: I believe the first half of your diamond is the issue here.

[dalgard]

Even if the signature becomes a bit bothersome to read, playing around with the nested array syntax is kind of fun – what if these two were equivalent, for example?

R.flow(f, [g, h, [i, j]], k)(x)
k(i(g(f(x))), j(h(f(x))))

The problem is that this structure looks recursive but isn't really. I think.....

[scott-christopher]

@benperez: I personally prefer these versions since they aren't variadic:

So do I, though the problem there is we don't have a native tuple type that we can return, meaning we can alternatively treat arrays as tuples (in which case we might as well extend to support variable-length arrays) or otherwise use functions via a church encoding of tuples:

type Pair a b = (a -> b -> c) -> c

flow   :: (a -> c) -> (b -> d) -> Pair a b -> Pair c d
fanout :: (a -> b) -> (a -> c) -> a -> Pair b c
first  :: (a -> b) -> Pair a c -> Pair b c
second :: (a -> b) -> Pair c a -> Pair c b

Which could be implemented via something like:

const flow   = curry((f, g, p) => p((x, y) => pair_(f(x), g(y))))
const fanout = curry((f, g, x) => flow(f, g, pair_(x, x)))
const first  = f => flow(f, identity)
const second = f => flow(identity, f)

Along with a couple of helper functions for constructing and deconstructing tuples:

//:: a -> b -> Pair a b
const pair_  = curry((a, b, z) => z(a, b))

//:: (a -> b -> c) -> Pair a b -> c
const unpair = curry((z, p) => p(z))

And then something similar to original request:

const f = inc
const g = multiply(8)
const h = divide(4)
const i = subtract

// equiv to: `x => subtract(multiply(8, inc(x)), divide(4, inc(x)))`
const f1 = R.pipe(f, fanout(g, h), unpair(i))
f1(1) // 14

// or with compose
const f2 = R.compose(unpair(i), fanout(g, h), f)
f2(3) // 31

// or something a little more involved
// equiv to: `x => subtract(divide(4, multiple(8, inc(x))), multiple(8, divide(4, inc(x))))`
const f3 = R.pipe(f, fanout(g, h), flow(h, g), unpair(i))
f3(1) // -15.75

[buzzdecafe]

@scott-christopher can we use ramda-fantasy Tuple type for Pair?

[scott-christopher]

@buzzdecafe: Sure. It could be used for a few other things too like toPairs, fromPairs and pair, but that's a whole new conversation to be had 😄

The other interest thing with the use of church encoding is that flow and fanout come very close to just being flipped versions of useWith and converge restricted to functions of two arguments.

[buzzdecafe]

this looks pretty familiar. pair_ is cons; first is like car, and second is like cdr but just slightly twisted.

const cons = (x, y) => (f) => f(x, y)
const car = (f) => f((x, y) => x)
const cdr = (f) => f((x, y) => y)

but the elaboration you are able to do with flow is a total revelation to me. Pretty exciting stuff

[arcseldon]

Found this moderately interesting and loosely related to this post - compose that takes an array as its argument in terms of compose with a fold right and identity initial accumulator.

describe('compose with array support in terms of reduceRight and Identity', () => {

    const mul100 = R.multiply(100);
    const add1 = R.add(1);
    const pipeline = [add1, mul100, add1];
    const compose = R.compose;
    const composeA = R.reduceRight(R.compose, R.identity);

    it('should work with compose and args as params', () => {
      const algo = R.compose(...pipeline);
      expect(algo(1)).to.eql(201);
    });

    it('should work with compose and args as array', () => {
      const algo = composeA(pipeline);
      expect(algo(1)).to.eql(201);
    });

  });