Monoid::foldRight was accumulating the accumulator from the left. This has been fixed but the identity is now used as a starting accumulator. Otherwise, the evaluation order is unchanged.
Changed ExplainFold parameter name since the accumulator can be in either position
SidenoteMonoid::foldMap seems to be where short-circuiting is currently implemented. Something that was going to be addressed in the incomplete https://github.com/palatable/lambda/pull/122/files. For obvious reasons, it doesn't seem to address semigroups that should short-circuit. In addition, it has some odd behavior for Monoid::foldRight. For example the function application will now match Semigroup::foldRight, but and().foldRight(true, repeat(false)).value() does not short circuit with the current implementation of Monoid::foldRight. I'm tempted to remove foldLeft/foldRight from Monoid and add a lazilyApply to Semigroup that would allow for users to override for short-circuiting behavior.
Addressing https://github.com/palatable/lambda/issues/127
Sidenote
Monoid::foldMapseems to be where short-circuiting is currently implemented. Something that was going to be addressed in the incomplete https://github.com/palatable/lambda/pull/122/files. For obvious reasons, it doesn't seem to address semigroups that should short-circuit. In addition, it has some odd behavior forMonoid::foldRight. For example the function application will now matchSemigroup::foldRight, butand().foldRight(true, repeat(false)).value()does not short circuit with the current implementation ofMonoid::foldRight. I'm tempted to removefoldLeft/foldRightfromMonoidand add alazilyApplytoSemigroupthat would allow for users to override for short-circuiting behavior.