Support Objects aka dictionaries as Traversables

[semmel]

As implemented elsewhere:

• in Sanctuary's S.sequence and S.traverse which work on Object
• in the Map type of Prof. Frisby's FP Guide
• in the Record type of fp-ts

[github-actions]

Coverage

> ramda@0.29.1 coverage:summary
> BABEL_ENV=cjs nyc --reporter=text-summary mocha -- --reporter=min --require @babel/register

�[2J�[1;3H
1188 passing (894ms)


=============================== Coverage summary ===============================
Statements   : 94.03% ( 2474/2631 )
Branches     : 85.73% ( 967/1128 )
Functions    : 93.24% ( 552/592 )
Lines        : 94.31% ( 2320/2460 )
================================================================================

[github-actions]

Coverage

> ramda@0.29.1 coverage:summary
> BABEL_ENV=cjs nyc --reporter=text-summary mocha -- --reporter=min --require @babel/register

�[2J�[1;3H
1188 passing (861ms)


=============================== Coverage summary ===============================
Statements   : 94.03% ( 2474/2631 )
Branches     : 85.73% ( 967/1128 )
Functions    : 93.24% ( 552/592 )
Lines        : 94.31% ( 2320/2460 )
================================================================================

[kedashoe]

#1067

I'm in favor of this, but maybe not before 1.0

[semmel]

TLDR: You can shoot yourselves in the foot with JavaScript, why not with Ramda too?

I just found #2580 which dealt basically with the same problem 6 years ago. That is really upsetting.

That PR got bikeshedded discussing the incompatibility of R.equals (which ignores key order) and a possible R.reduce for Object (which would observe key order and lead to different results unless the reducer function is commutative and associative).
Pretty everyone agreed that key order does not matter in Object, and that its not an issue traversing Object but the PR was never merged.

I guess people have moved on, since still today I cannot traverse a dictionary Object — which is pretty basic when you work with Maybe, Either and such data types.

So if PRs don't cut it, perhaps Ramda has hit an implicit barrier in supporting certain FP features?

The low entry barrier and no hand-holding attitude have been always the strengths of Ramda: You can solve problems quickly using

• JS-native data structures,
• suitable ADTs with Fantasyland support or not,
• even the pesky Promise.

out of personal frustration:
I think the fact, that Ramda will probably never reach v1.0 just reflects the fact that one can never fulfill all what is promised in those "FP using JavaScript" articles?

[kedashoe]

I hear you. As I said and as I argued in those earlier threads, I 100% think we should add Traversable for objects. But it does not feel right to me to have it 1.0, and I worry we'll get into another endless bikeshed if we try.

But we'll get to 1.0, and I think soon. I like getting flow in for it. Whatever else is on main. Do a v0.30. Then do v1.0 shortly after. The work @Harris-Miller is leading on the typescript side is phenomenal and deserves our continued vigilance here.

[Harris-Miller]

🤔

Plain objects are inherently treated as Functors for map() and as Filterables for filter(). Are they foldable? Represented as an array via toPairs() they are. If we were to add inherent support to reduce for objects it would essentially be compose(reduce, toPairs) since you'd have to represent it as a key/value tuple pair. (Update: Nevermind, that doesn't make sense, you can't use reducer callback interchangeably between object and arrays then. It would just be the value. If you want the key/value tuple, just use toPairs first). And given that you could implement both map() and filter() from that... I would say yes, objects are foldable. Plain objects have an empty ({}) and concat (Object.assign). And via inherent support from ramda, implement equals as well.

Seems reasonable to give the same support for Traversables, IMO

Additionally, Data.Map implements Traversable and it does exactly what is being asked here