Standard (core) libraries initiative: rationale
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
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?...
First, I should say that I am a Haskell newbie so consider what I say below as an 'external' point of view. About the language, after reading the Haskell98 report (and 'Haskell: the craft of functionnal programming') I found the language clean, simple, small and consistent. But I have also seen a lot of proposal for extensions on mailing lists and papers which may make Haskell' very difficult to learn because of the lack of history and evolution knowledge (the paper 'The History of Haskell' may help here). I think that keeping Haskell' minimal with a simple, consistent and clean syntax is very important to keep it attractive. This is probably the main reason why people come to Haskell (and why for example I will never use OCaml). It doesn't mean that new concept cannot be introduced (e.g. open data type), but it should be done with consistent and simple syntax in mind. About the libraries, I should say that I was a bit disappointed by the common use of the terms genericity and polymorphism (even in books). For example I have read many times that "length" is polymorphic or generic while it only computes the length of a list. It probably reflects that standard libraries do not provide enough *generic* API through the use of classes and overloading. If you look at Java evolution (not my favorite language), a lot of classes have been converted into interfaces to improve its flexibility and its evolution. In Haskell, most functions should be member of a generic API through classes and overloaded for common types like list (the paper 'Software Extension and Integration with Type Classes' may help here). This would incite developers to reuse the same API for their libs instead of creating dozen of variants of filter, map and fold and/or reinvent the wheel. If you look at language like CL or R which have thousands of functions, the vast majority of questions are 'how do I do this' because people are lost and don't even know where to start (the index is so huge). Finally, it may be worthwhile to include in the standard some description on some concept available in Haskell: laziness and monad. For example (I might be wrong), I understand monad simply as being: <> The *consequence* is that you can enforce *sequencing* because of the function evaluation semantic (function must be evaluated before you can use its returned value). And you can also *simulate* side effects because the 'thing' is never exposed. The latter being often not understood if you consider the FAQ 'how to get out of the IO monad?'. Finally, the rules associated with monads are just there to allow common usage, that is the composition of monad (e.g. in do notation) and the encapsulation of the 'thing' when entering the monad. Unless I am wrong, I have never seen a such simple description of monads which should allow programmers from other languages to understand the concept in a couple of minutes (better than talking about category theory ;-) . One could even consider monad as a design pattern since it is a common construction which solves a common problem. As a conclusion, I would say that I really like your initiative. my 2 c. Regards, ld.
Laurent Deniau
participants (5)
-
Bulat Ziganshin -
David Roundy -
Gabriel Dos Reis -
Ian Lynagh -
Laurent Deniau