Proposal: Add concatMapM function (#2042)

[Conor McBride]

Hi Duncan

On 30 Jan 2008, at 10:53, Duncan Coutts wrote:

>
> On Tue, 2008-01-29 at 12:53 +0000, Conor McBride wrote:
>
>> What's orthogonal to what, here? I'm trying
>> to understand why the generalization is
>> irrelevant (or merely unwelcome) to the
>> discussion of whether or not the special case
>> should be added to the library.
>
> I think the point is that it'd be a bit inconsistent if the only
> function in Control.Monad that was generalised to arbitrary  
> Traversable,
> Monoid etc was concatMapM.

This may be a reasonable distinction between
concerns, but they're hardly orthogonal. The
question of whether or not such generalizations
are likely or desirable, sooner or later, is
clearly relevant to the issue of how lame a duck
concatMapM is likely to be, hence whether or not
it should be added.

> The point continues that if we do indeed want
> to generalise all the functions in Data.List and/or Control.Monad then
> that should be a separate proposal.

An interesting question is the extent to which
this has already happened. My issue with
concatMapM has, all along, been that it is
a special case of foldMap, given the appropriate
instance of Data.Monoid. We don't have to
contemplate adding a new super duper general
thrudsplingblatter to the library, giving it a
silly name the better to travesty the mere
suggestion, because foldMap is already in the
library: it's a question of learning to make
more and better use of it.

I guess I'm advocating a general policy of "more
structures; fewer functions", exploiting the
power of instance inference to deliver the
usual structure-respecting whatever, rather than
giving all the instances individual names. Less
is more. Or maybe I'm just a grumpy old
math-troll trying to hassle people away from
getting on in the obvious manner with some
obviously desirable functionality.

You choose

Conor