In an earlier post in the thread I summarized a concrete list of what I thought might best be entailed, which is to take the generalized versions of the existing combinators from Data.Foldable and Data.Traversable, but not to go off and make up new things to generalize -- those I think rightfully belong in other proposals.
So, the intent of me and many of the others I interacted with in putting forth the proposal was very much in the spirit of interpretation (2).
The were however, two combinators in Data.Foldable that I wondered if we should include: Data.Foldable.concat and Data.Foldable.concatMap.
I'm pretty much neutral on their inclusion or exclusion.
Pros for including:
Consistency. Leaving them behind in Data.Foldable means that you get back to importing with name collisions for just two combinators.
Cons for including:
concatMap is subsumed by foldMap
concat is subsumed by both fold and by join for its role in (++)
One can concoct a scenario where you use MonadPlus combinators to build up a list and tear it down with the existing concat. This is arguably "crossing the streams" as you are building up with one class and tearing down with another class constraint with no law relating the two, and so using the old Prelude 'concat' could help inference along -- otherwise why were you invoking it in the first place?
Phrasing this as the intersection of the Foldable/Traversable API and the Prelude is interesting, because it would leave a few fold-like combinators in Data.Foldable alone. I'm somewhat neutral on whether we bring in the rest of the foldlM, etc. but if we're bringing in Foldable, I'd like to at least see foldMap, but that carries with it the caveat that foldMap references Monoid, which is not currently in the Prelude (and traverse references Applicative, also not currently in the Prelude).
Assuming the Applicative m => Monad m proposal goes through at the same time (which seems exceedingly likely given the current polling, the Applicative class would wind up in the Prelude, resolving the tension for the latter, but exporting foldMap means we'd want at least the Monoid class as well.
So to summarize the particular point in the design space that I've been advocating and spell out some of its consequences:
The Prelude then exports Foldable(..), Traversable(..), Applicative(..), and Monoid(..).
We upgrade the combinators in Prelude with the ones from Foldable and Traversable that collide with the existing names -- along with whatever resolution folks want on concat/concatMap.
Data.Foldable continues to export the few folds that weren't in the Prelude or someone makes a case for bringing them in too, and it also re-exports Foldable(..) and the combinators we moved, to facilitate the non-breakage of existing code.
Data.Traversable re-exports Traversable(..) and provides foldMapDefault, fmapDefault, mapAccumL and mapAccumR.
Data.Monoid would still continue to hold the existing monoids, (<>), and re-exports Monoid(..).
Control.Applicative would still continue to export the instances, Alternative(..), combinators, and re-exports Applicative(..).
-Edward