Hello Twan, Thursday, January 17, 2008, 2:00:37 AM, you wrote:
An often requested function is 'split', to split a list into parts delimited by some separator. ByteString has the functions split and splitWith for this purpose. I propose we add equivalents to Data.List:
one more proposal to ruin all the programs that define this function themselves. i wonder whether all who propose to add function or two ever seen MissingH package? it includes a lot of such popular functions and anyone who needs them can install this package (or just borrow code) i make a contra-proposal - fix base library in 6.8 state and add to ghc distribution new libs with all the popular Monad, List and any other functions. this will allow: 1) precisely control which functions are available by importing exact versions of all libs (except of base which anyway will be frozen) 2) use all the new functions regardless of ghc version you are using. otherwise, adding `split` function to the base actually means that noone except for core hackers can use it for a year - because all these changes in base will go in production GHC version at the end of 2008 and because using user-defined split function will automatically make program incompatible with next GHC version overall, i want to use GHC for production, open-source programming and can formalize requirements which will allow to do this: 1) frozen base library interface, except for GHC.* modules 2) if we want to improve some base code, we *duplicate* it into new lib (with modified module names), publish first version of this libarry with exactly original code (and therefore equivalent interfaces) and then start to improve it, publishing newer and newer versions. imagine, for example, that we want to improve Data.Array.*: step 1: create library NewArray with modules Data.NewArray.* copied one-to-one from Data.Array.* and publish it as version 1 step 2: raise NewArray version to 2.0 and start making changes. once we've finished, raise version to 3.0 and keep interfaces for 3.* intact so anyone can import NewArray 3.* and got latest version with exactly the same interface as he used yes, this means that every functionality improved against the base package, should be installed in two versions - one inside base one in new package. but this is very natural taking into account that we can't change base without breaking all the code that relies on it. so, if we want new arrays, Handles or Exceptions - we will need to keep old version in base and add new one in other lib. overall, it should be recommended to not import directly anything from base but use separate libraries instead 3) GHC distribution should include all the popular libs (which, at the last end, should terminate rushes to include "popular functions" into the base!) with *MULTIPLE* versions - i.e. last 1.* version of NewArray, last 2.* version and so on. this will ensure that program developed in year 2007, will continue to compile with newest ghc versions in 2008, 2009 and so on. we can drop library from ghc distribution after, say, 3 years. i also propose that Haskell' ccommittee will decide every year which libs to include into Haskell standard libs set with exact major version. for example: year 2007: BS 1.*, Collections 2.*, HDBC 1.* year 2008: BS 2.*, Collections 2.*, HSQL 1.* year 2009: BS 2.*, Collections 2.*, HSQL 2.* ghc-2009 should include std libs from last 3 years, i.e. BS 1.*/2.*, Collections 2.*, HDBC 1.*, HSQL 1.*/2.* ghc-2010 may drop BS 1.* and HDBC 1.* support and of course should add newer libs from HL-2010 standard. the same should do other haskell compilers. this will significantly improve situation with Haskell standard libraries: 1) Haskell' committee will not need to develop artificial "standard libraries" set - actually, i think it can't and anyway any fixed set will become obsolete next year. libraries are most important part of any language and nowadays we can't develop proper stdlibs set "by committee". it should be made by community and committee should only "sign up" final results 2) every haskell distribution will include some guaranteed minimum of common, up-to-date libraries. any program written using H2009 specifications, will continue to run with any major Haskell compilers for a next 3 years. this should overcome "libraries hell" for mid-sized apps 3) any book or courses teaching Haskell can declare, for example, that it investigates Haskell-2009 and any Haskell2009-compatible compiler will provide both the syntax and libs discussed in the book. it will also mean that when you hire "Haskell2009-certified" specialist, you will be sure that he knows not only the language itself but also basic set of libs, equivalent of STL for C++ defining large standard set of libs was the major source of success for Java/C#/C++ last decade. we can go one step further and join development by community with standardization by committee. it should make Haskell better solution for developing large, long-standing products - by providing RICH set of MODERN STANDARD libs, which are guaranteed to run across compilers and years. criteria of inclusion library in this set are (obvious): 1) popularity (this can be fairly measured by downloads/installations/ user votes) 2) open-source, free license, unix/win and ghc/hugs compatibility -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com