Hello libraries, 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?... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
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 question mirrors the base/core/whatever package question, of course, and I certainly don't know best which modules need to go into the core set of libraries defined by Haskell', but I'd like it to be minimal in the sense that I'd like to not see libraries included that could practically be implemented on top of the other libraries. e.g. System.Process (if sufficiently well-defined and/or portable) probably should go in, as those functions are most likely impossible to implement in portable Haskell', even with the FFI. It'd be nice, though, to see some work towards a set of "standard" (either de facto or otherwise) libraries developed to work nicely with Haskell', once that exists. But my guess is that it'd be best to wait quite a while before setting anything in stone, just because it's so hard to get an API right. -- David Roundy Department of Physics Oregon State University
On Mon, Nov 27, 2006 at 02:55:03PM -0800, 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.
Right, the problem is that there is a tension here between having the ability to fix and evolve the libraries, and people wanting to write books on how to use Haskell' (without having to define (+) and map etc themselves). We've been lucky thus far that having the hierarchial libraries completely disjoint with the report has meant that we have been able add to and alter things even in the base package without breaking anything assuming Haskell98. We haven't had to worry about clashing with a user's Data.Function module, or if adding an "on" function will cause ambiguous-import errors in someone's program. We still get the occasional person in #haskell asking why they can't find the fromInt their book talks about, and I think that was probably published in the 90s? I've been pondering this all day, and I think my conclusion is that books should be about "Haskell', base 3.0.* and mtl 2.1.*", and Haskell' should say pretty much nothing about libraries (we'll probably want to use things like head in examples, and talk about things like seq; hmm, perhaps a very few functions like seq do belong in a package of their own that Haskell' knows about, probably reexported elsewhere by the base package). This would be more reason for GHC to factor out the magic from base, as it'll be possibly more important to be able to install base 3.0 and 4.1 simultaneously. Thanks Ian
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
participants (4)
-
Bulat Ziganshin -
David Roundy -
Ian Lynagh -
Simon Marlow