Changes between Initial Version and Version 1 of Commentary/Packages/PackageReorg/Rationale


Ignore:
Timestamp:
Nov 27, 2006 8:12:29 PM (13 years ago)
Author:
Bulat
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/PackageReorg/Rationale

    v1 v1  
     1like "computer is a net", nowadays language is a library. there is
     2nothing exceptional in C++ and Java languages except for their huge
     3library codebase that makes them so widely appreciated
     4
     5while it's impossible for Haskell to have the same level of libraries
     6maturity, we can try to do our best. Libraries was considered so
     7important, that in H98 report libs required more pages than language
     8itself. But, really, all libraries described there together is
     9appropriate only for learning and small programs - to do real work, we
     10need even much, much more
     11
     12fortunately, now we have large enough set of libs. moreover, this set
     13grows each year. but these libs don't have official/recommended
     14status. now we have two languages - H98 as reported with its bare
     15libs, which is appropriate only for teaching, and real Haskell
     16language with many extensions and rich set of libs, used to develop
     17real programs
     18
     19with a language itself, now we go to standardize current practice and
     20include into language definition all popular extensions. this will
     21close the gap between standard and practice. Haskell' committee also
     22plan to define new version of standard Haskell library. but what a
     23library can be defined in this way? slightly extended version of
     24standard Haskell98 lib? or, if it will be significantly extended - how
     25much time this work will require and isn't that a duplication of work
     26done at libraries list?
     27
     28i propose not to try to define reality, but accept existing one and
     29join committee's work on new library definition with a current
     30discussion of core libraries, which should define a set of libs
     31available on any Haskell compiler on any platform - aren't goals the
     32same?
     33
     34instead of providing rather small and meaningless standard Haskell
     35library, now we can just include in Report docs existing and widely
     36used libs, such as Network, mtl and so on. This will mean that
     37language, defined in Haskell standard, can be used to write real
     38programs, which will be guaranteed to run in any Haskell environment.
     39
     40of course, this mind game can't change anything in one moment. but it
     41will change *accents*
     42
     43first, Haskell with its libraries will become language for a real
     44work. such extended language isn't small nor easy to master in full,
     45but it is normal for any mature programming environment. people
     46learning Haskell should select in which area they need to specialize -
     47be it gaming or web service development, and study appropriate subset
     48of libs. people teaching Haskell now can show how *standard* Haskell may
     49be used to solve real world problems, and this should change treatment
     50of Haskell as academic language. also, we may expect that books
     51teaching Haskell will start to teach on using standard libs, while
     52their authors now don't consider teaching for non-standard libs
     53
     54second, by declaring these libs as standard ones we create sort of
     55lingua franca, common language spoken by all Haskell users. for
     56example, now there are about 10 serialization libs. by declaring one of
     57them as standard, we will make choice simpler for most of users (who
     58don't need very specific features) and allow them to speak in common
     59language. in other words, number of Haskell libs is so large now that
     60we should define some core subset in order to escape syndrome of Babel tower.
     61defining core libraries set is just sharing knowledge that some
     62libraries are more portable, easier to use, faster and so on, so they
     63become more popular than alternatives in this area
     64
     65third. now we have Cabal that automates installation of any lib. next
     66year we will got Hackage that automates downloading and checking
     67dependencies. but these tools still can't replace a rich set of
     68standard libs shipped with compiler. there are still many places and
     69social situations where Internet downloading isn't available. Compiler
     70can be sold on CD, transferred on USB stick. and separate Haskell libs
     71probably will be not included here. Standard libraries bundled with
     72compiler will ensure that at least this set of libs will be available
     73for any haskell installation. Internet access shouldn't be a
     74precondition for Haskell usage! :)
     75
     76fourth. now there is tendency to write ghc-specific libs. by defining
     77requirements to the standard libs we may facilitate development of
     78more portable, well documented and quick-checked ones. or may be some
     79good enough libraries will be passed to society which will "polish"
     80them in order to include in the set. anyway, i hope that *extensible*
     81set of standard libraries with a published requirements to such libs
     82would facilitate "polishing" of all Haskell libs just because ;)
     83
     84
     85and this leads us to other question - whether this set and API of each
     86library should be fixed in language standard or it can evolve during
     87the time?...