Standard (core) libraries initiative: rationale

[Gabriel Dos Reis]

Laurent Deniau <laurent.deniau at cern.ch> writes:

[...]

| 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. 

I suspect that reflects a common view, that the list datatype
is The materialization of the notion of sequence -- anything else is
either obscure or marginal or perversion :-/

| 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). 

I agree with what you say.  However, the trouble with is that a
descent job at categorizing and implementing containers with type
classes will require, at the minimum, multi-parameter type classes
functional dependencies, associated types or equivalents.  Those
topics seem to be subject of heated debates among seasoned Haskellers.
Personally, I'm looking forward to a standardization of
multit-parameter type classes with functional dependency -- at least a
blessing of the parts that "work". 

Simon PJ has an excellent paper on "bulk types with class" that you
might want to consult for some thorny issues.

[...]

| 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.

And change the name "monad" to something less scary for common
programmers too? :-)

-- Gaby