Proposal: Add concatMapM function (#2042)

Henning Thielemann lemming at henning-thielemann.de
Tue Jan 29 10:35:28 EST 2008


On Tue, 29 Jan 2008, Twan van Laarhoven wrote:

> Twan van Laarhoven wrote:
> > I have noticed that many projects include a 'concatMapM' function:
> >
> >   concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b]
> >
> > Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042
> > Deadline for discussion: 2 weeks from now, January 28
>
> Deadline <= now, so here is a summary of the discussion:
>
>    1. In favor:
>       - Twan van Laarhoven
>       - Isaac Dupree
>       - Don Stewart
>       - Neil Mitchell
>
>    2. Sidetracked with discussion of generalizations:
>       - Yitzchak Gale
>       - apfelmus
>       - Ross Paterson
>
>    3. Opposed to any additions to the base library:
>       - Bulat Ziganshin
>
> I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ
> for now :). On the other hand, Bulat raises a valid point.

 In consider Bulat's point as preservation of unfavorable coding style
(namely unqualified anonymous import). This method does not scale well and
you can motivate stop of any development this way. So I object to Bulat's
argument, but not necessarily vote particularly for concatMapM, since I
didn't need it so far - which can also mean, that I have always
worked-around it without noticing it.
 I think a generalization to Traversal would be nice. This would make
these classes certainly more useful.

> Adding things to the
> base library might break some programs, although they will be easy enough to
> fix. But what do we do with Bulat's point in this specific case? I see two options:
>
>    a. Don't add anything to the base libraries anymore, ever.

The current state is: Prelude's list functions are imported automatically
and unqualified and thus should not be extended. However Data.List
functions must be imported explicitely and then should be imported
qualified or by name. This does not only avoid name clashes but also
simplifies reading programs.
 http://www.haskell.org/haskellwiki/Import_modules_properly

>    b. Go ahead and add the function. Most users will see the change as they
> upgrade to ghc 6.10, which might break other minor things anyway.

This would be a good opportunity to switch to a more friendly importing
style.


More information about the Libraries mailing list