foldMapOf fails with an empty target

[scott-christopher]

The following code should evaluate to 0, however it currently fails.

foldMapOf(folded, Sum, []);

The is due to foldMap expecting at least one pass through the reduce function to pull an empty value off the monoid instance.

var foldMap = curry(function(f, fldable) {
  return fldable.reduce(function(acc, x) {
    var r = f(x)
    acc = acc || r.empty()
    return acc.concat(r)
  }, null)
})

This should ideally be passing in a monoid type in as an argument in order to populate the initial reduce value with its empty() value.

var foldMap = curry(function(M, f, fldable) {
  return fldable.reduce(function(acc, x) {
    var r = f(x)
    return acc.concat(r)
  }, M.empty())
})

I'm not sure how we can work around this as gets pretty messy trying to find a suitable point in the call chain to pass in the correct monoid type.

[buzzdecafe]

sounds awfully familiar: fantasyland/fantasy-land#88 (comment)

and i do mean "awfully"

[DrBoolean]

Yeah...same deal for traverse though it threads point through on that one. I suppose the only fix is passing empty around despite the difficulty.

[scott-christopher]

How do others feel about removing fold.js in order to get a release going? We could bring it back in afterwards if we can come up with a solution for this.

[DrBoolean]

I'm good for that!

[DrBoolean]

alternatively we can act like JS:

[1].reduce((acc, x) => acc + x)
// 1

[].reduce((acc, x) => acc + x)
Uncaught TypeError: Reduce of empty array with no initial value(…)

but that's not great

[buzzdecafe]

i think we have consensus; let's get folds.js out of the way in order to release 0.1.0.

move folds.js to a branch in the meantime?

[Koleok]

@buzzdecafe yes and yes 👏

[scott-christopher]

Don't know that I'm proud of it, but I've managed to get foldMapOf working.

master...scott-christopher:alt-fold

The "don't look at me like that" part comes from binding the Applicative m => { of :: a -> m a } to the lens when called in over and view to allow access to it in things like traversed

🙈 ... but it seems to work.

const
  { compose
  , lensProp
  } = require('ramda'),

  { foldMapOf
  , over
  , traversed
  , view
  } = require('.');

const Add = x => ({
  concat: y => Add(x + y.value),
  value: x
});

const l = compose(lensProp('x'), traversed, lensProp('y'));
const obj = { x: [{ y: 1 }, { y: 2 }, { y: 3 }] };

view(l, obj);                         //=> 1
over(l, x => x * x, obj);             //=> { x: [{ y: 1 }, { y: 4 }, { y: 9 }] }
foldMapOf(l, [], x => [x], obj);      //=> [1, 2, 3]
foldMapOf(l, Add(0), Add, obj).value; //=> 6

[DrBoolean]

Haha! You brilliant bastard. Well, dynamic typing gonna dynamic. If you regard the types as an ambient environment of information, then storing this information in this doesn't seem that crazy.

+1 from me

[Koleok]

i am so happy

[Koleok]

So whats the consensus guys? I just want this to be on npm like nobodies business

[buzzdecafe]

fine with me

[scott-christopher]

There's a PR for this in #8