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

[Heinrich Apfelmus]

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

You mean, like this?

   http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png


It's a project that I'm currently working on, called

     HyperHaskell
     - the strongly hyped Haskell interpreter -

Well, it's supposed to be strongly hyped, but currently, only few people 
know about it. Could you give me a hand with, uh, hyping this? I'm not 
good at this.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


Olaf Klinke wrote:
> 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
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.