On Fri, Mar 14, 2008 at 2:50 PM, Andrew Coppin wrote:

Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery.

Well, there wouldn't be much point to a type system extension if you could do just as well without it.

And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is?

It's because Haskell is, among other things, a research language. Part of its stated purpose is providing a basis for experimenting with type systems and implementation strategies and so forth. When Haskell 98 was written, higher-ranked polymorphism wasn't considered practical, and no one had invented multi-parameter type classes yet. Even type classes started out as an experiment, and then they were extended to constructor classes (e.g., classes like Monad where the parameter is a type constructor, not a ground type). Eventually, the most successful extensions will be rolled into the next Haskell standard. The same thing happens in Java. Generics (what we call type constructors) were available in various extended Javas before being added to the main standard. The Haskell process is just a lot slower because we're doing things very few have done before. -- Dave Menendez http://www.eyrie.org/~zednenem/

Andrew Coppin wrote:

Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery.

And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a "type" is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare.

And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is?

I think this is at least partly because Haskell takes being a (typed) functional language very serious. With OO languages, such as Java or Eiffel, you can swipe a lot of the complexity under the stateful object carpet. Functional programs explicitly operate on values, however complex their types may be... and thus themselves become values with even more complex types... I found this paper http://www.eecs.usma.edu/webs/people/okasaki/pubs.html#jfp98 quite illuminating (it uses SML, not Haskell, which rather confirms my point). Cheers Ben

Hi Andrew, Andrew Coppin wrote:

Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery.

And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a "type" is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare.

There are a lot of Java extensions in various directions (Multimethods, Mixins, Virtual Classes, Aspects, Effect Typing). Some extensions have been included into the "official" Java Language (Anonymous Classes, Generics). Other extensions have lead to the creation of new languages different from, but related to Java (Scala). A lot of research teams, both academic and industrial, are working on new extensions of the Java Language. Such extensions may come as libraries, preprocessors or compilers, they may reuse, extend or substitute the run time system. From my limited view, the Java research community seems to be bigger then the Haskell research community. But I may be wrong here, and the meaning of a "big community" isn't clear at all, so that's not the point. Clearly, Haskell feels like a research language, and Haskell hacking is like pushing the border into unexplored territory, while Java feels like a lot of boilerplate without actual content, and Java development is like taking care of paperwork. Why is this the case? I see four reasons all working together: First, Java is designed for the software industry, while Haskell "avoids success at all cost". This means that we have 90% research people working with Haskell, and 0.01% research people working with Java, *even if there are more Java researchers as Haskell researchers*. It's the absence of non-researchers which makes Haskell a research language, not the abundance of researchers. Second, Java extensions tend to be incompatible with each other, since they typically consist of an modified compiler, while Haskell extensions tend to get integrated into GHC or lost forever. With GHC as de-facto standard compiler, we have a number of extensions available for every productive Haskell system. Third, the theoretical base of pure functional languages is relatively clear and easy to understand, while the theoretical base of imperative object-oriented languages is still widely unexplored and hard to grasp. This means that formal, scientific papers about Haskell are more likely to be user-understandable then formal, scientific papers about Java. Ever seen one of the formal calculi proposed as semantic core of the Java language? Fourth, Haskell is just better. (Had to include this one to avoid being victim to a flame war). But hey, it is my personal opinion too. Tillmann