ramda: `all` fails on objects?

@dmitriz, you might prefer S.all:

> S.all (S.lt (5)) ([1, 5])
false

> S.all (S.lt (5)) ([1, 2, 3])
true

> S.all (S.lt (5)) ({a: 1, b: 5})
false

> S.all (S.lt (5)) ({a: 1, b: 2, c: 3})
true

@dmitriz:

A proposed implementation is only the start of a PR…

If you want much stricter guarantees, you should take a look at Sanctuary.

@ivenmarquardt:

[Referential transparency] and immutability are also “policies” of Ramda, because native JS lacks both features. So saying that Objects should only be treated as namespaces and records is merely another policy based upon this.

I make a big distinction between how Ramda acts on its own and what we expect from users working with Ramda. While Ramda won’t mutate your data, it works perfectly well, for instance, with a function passed to reduce that mutates the accumulator object. Ramda simply doesn’t care. While I don’t feel any need for foldObj, it’s a very common request, and my only objections have to do with the issue of commutativity. If that’s removed, then it seems to me a reasonable request.

Functions are only one part of FP, the morphisms. The types are the objects with which the morphisms can work.

By mentioning LISP, I was trying to point out that there are languages widely considered to be functional that don’t follow the ML strongly typed style. Category theory is certainly a useful basis for some FP languages, but it’s not the only one.

@dmitriz:

I see two problems with using Sets for any of our work.

First, Ramda has been trying to maintain compatibility with older versions of the language, something I want to give up as soon as we pass version 1.0. But we never seem to be getting to that.

Second, Sets are designed around reference equality, not the value equality that suffuses Ramda. That makes it quite difficult to use them for these purposes. But we do have an internal implementation that might do in _Set.

Nonetheless, I really like the idea of adding a CFold implementation alongside our current reduce. Obviously it would be up to the user to enforce commutativity in their fold functions, but for those who really want foldObj, we could finally give them something useful.

considering how many there are, I would like to find a generic way to do so.

For what it’s worth, all is just foldMap using the boolean and as the monoid. The other ones listed could also be implemented via foldMap with a suitable choice of monoid.

That could lead the way to a suitable abstraction here.

https://goo.gl/Hf7tBB