[Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)

[Olaf Klinke]

I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. 

I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict. 

I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. 
In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. 
So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient. 

As to what kind of batteries should be included: 

* I feel that Haskell already has an excellent set of containers for all sorts of tasks. 
* It has excellent parsers. 
* The web stuff seems less uniform, and my complaints about idioms apply. 
* To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. 
* I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. 

I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks. 

As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures. 

Olaf