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@gmail.com