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:
<<A container which *encapsulates* 'something' and a companion function to transform this 'thing' (within the monad)>>
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. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
