David Roundy wrote:
On Mon, Nov 27, 2006 at 10:28:09PM +0300, Bulat Ziganshin wrote:
[...] 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?...
To me, this is the deciding issue. The Haskell 98 libraries have some severe issues which are unfixable because they're defined as part of the standard. My preference for Haskell' would be to have a *reduction* in the size of the core libraries. For example, the Time and Locale modules are pretty much useless, and totally unnecessary, since they can be easily implemented in Haskell 98.
Yes, it would be nice to have at least a de facto standard set of libraries, but this is best done apart from the language standardization process. This has worked reasonably well so far, and has mostly been hampered by the limitations of Haskell 98, which mean that relatively few libraries support the standard Haskell language. I'd like to see work on a standard set of libraries follow Haskell', with the libraries being written in pure Haskell'. The libraries defined in the standard should be limited to those which are either universally used or necesary in order to implement the rest of the libraries.
This pretty much echoes my thoughts on the issue too. And we've talked about it in the context of Haskell': the current plan is to do exactly what you suggest and have only a very minimal set of libraries standardised as part of the Haskell' language. On top of this will be a much larger set of standard libraries, but these will be standardised by a process (and committee) separate from the Haskell' committee. There was a general concensus amongst the Haskell' committee for this approach. It might make sense for the current "Core Libraries" proposal to coincide with the Haskell' standard libraries process, but I imagine the latter will subject every library to a lot more scrutiny and hence will take a lot longer. In the meantime, we want something cheap and useful, which is what "Core Libraries" should be. Cheers, Simon