These are chat archives for ramda/ramda

3rd
Sep 2016
LeonineKing1199
@LeonineKing1199
Sep 03 2016 16:04

Okay, so I've been complaining in this gitter about not being able to iterate multiple ranges in a single pass. Well, I was looking through the reduce source code and I learned that reduce actually supports iterables!

So, I came up with a zipRange which is a variadic function that returns an iterable. Basically, a zipIterator is an iterator that iterates over a tuple of iterators. A zipRange is a finitely bound range of a zipIterator. As an example, consider this:

    it('should be iterable by other libraries', () => {
      const a = [0, 1, 2];
      const b = [3, 4, 5];
      const c = [6, 7, 8];

      const tupleSum = R.reduce((acc, tuple) => {
        const sum = tuple.reduce((total, v) => total + v);
        console.log(`${tuple} => ${sum}`);
        return R.append(sum, acc);
      }, [], zipRange(a, b, c));

      assert.deepEqual(tupleSum, [9, 12, 15]);
    });

/*
0,3,6 => 9
1,4,7 => 12
2,5,8 => 15
*/
So, zipRange is basically a way of reducing over a variable number of iterables in a single pass. zipRange supports any and all iterables including array, Map, Set, user-defined types.
LeonineKing1199
@LeonineKing1199
Sep 03 2016 16:11
The source code for zipRange is right here.
Rafe
@rjmk
Sep 03 2016 16:31

@aaronmcadam How much control do you have over the API? Could you

const fetchTasks = requestData => R.composeP
  ( mapTasks
  , R.compose(requestData, getEndpoints)
  )

? That only leaves you with one point. I imagine it's possible to get it properly pointfree by currying R.composeP and flipping a Sanctuary-style compose, but probably not a good idea

Aaron Mc Adam
@aaronmcadam
Sep 03 2016 16:34
Ah yes I think that's not too bad, thanks @rjmk!
Rafe
@rjmk
Sep 03 2016 17:09
The fully pointfree version would probably look something like
R.compose(R.curryN(2, R.composeP), mapTasks, R.flip(S.compose)(getEndpoints))
Not the worst pipeline in the world, but I prefer the one above