Proposal: Add concatMapM function (#2042)

[Bulat Ziganshin]

Hello Twan,

Tuesday, January 29, 2008, 3:11:45 PM, you wrote:

> I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ
> for now :). On the other hand, Bulat raises a valid point. 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:

i have several hundred one-liners in my Utils.hs. with such speed of
adding these funcs to the base, you will add only these funcs the next
10 years. does this mean that haskell hackers will continue to mutate
the language these next 10 years? :( 

i appeal to Haskell authorities - please agree with me in recognizing
importance of language stability and take this decision. just a list
of problems due to mutations in base library i've senn on the list in
this few weeks:

1) hackage libs are compatible with only one version of ghc. in
particular, when new version of ghc arrives, hackage is useless for it
and this delays its adoption. some times later, this becomes pain for
users of old ghc version. this also means that noone can just release
his code as a library - he need to update it every year. moreover,
this makes initiatives like cabal-install rather strange thing - that
is advantage of automatic downloading/compilation if sometimes we need
to edit cabal files?

2) unix ports are usually don't update to next ghc versions for a long
time because this "breaks compilation of many things"

3) even shootout tests were not updated to 6.8 because it breaks
compilation of these tests!

4) every week we see complaints from users who can't compile code
written for previous ghc versions

overall, i think that its hackers thinking - "required changes are trivial,
so everyone can do it". there are many agents (non-haskellers, even
non-programmers, automation tools) that can't do even trivial changes
in haskell code/configs. and even for a experienced haskeller who was
bothered to find info about required changes, this may be a good
amount of work (when we change lot of modules/libs) and they have
(like me) more restrictive requirements when we need to offer
compatibility with many ghc versions

so this is a headache without any real advantage. i propose to make
new lib, supply it with the ghc, and include all new functionality
here. at least this lib may be properly-versioned or not used at all


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com