|Version 2 (modified by simonmar, 5 years ago) (diff)|
like "computer is a net", nowadays language is a library. there is nothing exceptional in C++ and Java languages except for their huge library codebase that makes them so widely appreciated
while it's impossible for Haskell to have the same level of libraries maturity, we can try to do our best. Libraries was considered so important, that in H98 report libs required more pages than language itself. But, really, all libraries described there together is appropriate only for learning and small programs - to do real work, we need even much, much more
fortunately, now we have large enough set of libs. moreover, this set grows each year. but these libs don't have official/recommended status. now we have two languages - H98 as reported with its bare libs, which is appropriate only for teaching, and real Haskell language with many extensions and rich set of libs, used to develop real programs
with a language itself, now we go to standardize current practice and include into language definition all popular extensions. this will close the gap between standard and practice. Haskell' committee also plan to define new version of standard Haskell library. but what a library can be defined in this way? slightly extended version of standard Haskell98 lib? or, if it will be significantly extended - how much time this work will require and isn't that a duplication of work done at libraries list?
i propose not to try to define reality, but accept existing one and join committee's work on new library definition with a current discussion of core libraries, which should define a set of libs available on any Haskell compiler on any platform - aren't goals the same?
instead of providing rather small and meaningless standard Haskell library, now we can just include in Report docs existing and widely used libs, such as Network, mtl and so on. This will mean that language, defined in Haskell standard, can be used to write real programs, which will be guaranteed to run in any Haskell environment.
of course, this mind game can't change anything in one moment. but it will change *accents*
first, Haskell with its libraries will become language for a real work. such extended language isn't small nor easy to master in full, but it is normal for any mature programming environment. people learning Haskell should select in which area they need to specialize - be it gaming or web service development, and study appropriate subset of libs. people teaching Haskell now can show how *standard* Haskell may be used to solve real world problems, and this should change treatment of Haskell as academic language. also, we may expect that books teaching Haskell will start to teach on using standard libs, while their authors now don't consider teaching for non-standard libs
second, by declaring these libs as standard ones we create sort of lingua franca, common language spoken by all Haskell users. for example, now there are about 10 serialization libs. by declaring one of them as standard, we will make choice simpler for most of users (who don't need very specific features) and allow them to speak in common language. in other words, number of Haskell libs is so large now that we should define some core subset in order to escape syndrome of Babel tower. defining core libraries set is just sharing knowledge that some libraries are more portable, easier to use, faster and so on, so they become more popular than alternatives in this area
third. now we have Cabal that automates installation of any lib. next year we will got Hackage that automates downloading and checking dependencies. but these tools still can't replace a rich set of standard libs shipped with compiler. there are still many places and social situations where Internet downloading isn't available. Compiler can be sold on CD, transferred on USB stick. and separate Haskell libs probably will be not included here. Standard libraries bundled with compiler will ensure that at least this set of libs will be available for any haskell installation. Internet access shouldn't be a precondition for Haskell usage! :)
fourth. now there is tendency to write ghc-specific libs. by defining requirements to the standard libs we may facilitate development of more portable, well documented and quick-checked ones. or may be some good enough libraries will be passed to society which will "polish" them in order to include in the set. anyway, i hope that *extensible* set of standard libraries with a published requirements to such libs would facilitate "polishing" of all Haskell libs just because ;)
and this leads us to other question - whether this set and API of each library should be fixed in language standard or it can evolve during the time?...