w3rs/reducers — comment on commit 7e34ce664564c2696b261bdf4f0dfe9af3750434
File:  line 0
By w3rs:

On Sat, Dec 3, 2011 at 11:08 AM, Edward A. Kmett <
reply@reply.github.com
> wrote:

> The cons vs mappend issue I'm on board with but renaming those functions
> introduces alaising between the generator module and the semigroup reducers
> which are needed to power it. This forces the use of qualified imports that
> weren't needed before, and which break change the style of use and almost
> every package I have that builds on top of this.
>

I did simple google search on
hackage,
and there is only one source
filewhich
imports both Generator and Reducer in non-explicit manner, and uses
`reduce` function. I don't like `foldMapReduce` naming style because `fold`
is synonym to `reduce` (in functional programming), and `foldMap` means the
same as `mapReduce`, so `foldMapReduce` is like a tautology. And how to
rename mine `mapMaybeReduce`? `foldMapMaybeReduce` is too long name for a
quite simple function, and it's very unintuitive.

If you have never used `foldMapReduce`-like functions in other packages,
maybe you'd like to rename them to `mapReduce` fashion as I propose and
move them to separate module, like `Data.Foldable.Reduce` or similar? This
way we have no name ambiguity when we import both `Data.Generator` and
`Data.Semigroup.Reducer` and still we have similar `mapReduce` API for
Generator and Foldable.

> There are more Generators than Foldables, since every Foldable can be made
> into a generator, but things like Bytestring are generators but not
> Foldable, hence the assignment of the longer (and different!) names to The
> Foldable versions.
>

Generator is more powerful, but I mostly work with `Map`'s now, and it's
more convenient for me to `foldMapReduce f map` than `mapReduce f (Values
map)` if I don't need to use key values. Though, maybe I'll change my
opinion and prefer Generator style in future.