Standard (core) libraries initiative: rationale

[Laurent Deniau]

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.