ramda: addIndex(partition) gives incorrect results

i’d rather add mapi (and friends) rather than have addIndex(map) promise more than it can deliver.

Perhaps I didn’t explain my thought clearly. The point I was trying to make is that generalized functions such as reduce and filter cannot possibly provide array indexes.

I was noting that if we are going to remove dispatching, then these generalized functions may not matter, and we should worry once again only about lists. For lists, indices are at least somewhat reasonable.

I would certainly be willing to consider removing addIndex, but I think it would take a lot of convincing, as it’s one of those tools that helps ease JS people into FP.

These methods are not as ergonomic as Ramda functions: they don’t support partial application in such a convenient manner and in some cases need to be wrapped in anonymous functions to avoid losing context. I can live with this, though, as Ramda needn’t solve every problem.

I think this is a serious point of disagreement. Solving these ergonomic issues was my initial goal with Ramda. While the library has certainly grown beyond that, it’s very hard to see such issues dismissed.

There’s a type error in your version, @jonahx:

S.chain(R.head, [['a', 'b'], ['c', 'd'], ['e']]);
// ! TypeError: Type-variable constraint violation
//
//   chain :: Chain m => (a -> m b) -> m a -> m b
//                             ^^^     ^^^
//                              1       2
//
//   1)  "a" :: String
//
//   2)  [["a", "b"], ["c", "d"], ["e"]] :: Array (Array String)
//
//   Since there is no type of which all the above values are members, the type-variable constraint has been violated.

R.head is not of the required type, Chain m => a -> m b. You could use map + head instead. The erroneous version happens to work, of course, but it’s unwise to rely on implementation details. 😉