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
