So C# (3.0) has lambdas, list-processing functions, some good amount of type inference … hey, who would have thought that mainstream OO programming would get so much less dysfunctional say just 2 years ago. Now Haskell is cool for many reasons other than just plain higher-order functions. Some people are keen of laziness; others think this is the problem with Haskell. Then we have dreaded monads of course; not sure that they will make it in their full power (think of IO, STM) into say C# 4.0. Well, C# 3.0 has some ‘wacky’ form of monads, though. (return is called select; bind is called from … in …, the list monad took over a bit too much.) Finally, Haskell is so particularly cool because of type classes, and I have wasted a good part of my life hanging out with Oleg and other geeks to understand what type classes can really do for you.
So suppose OO programming actually takes off (and replaces Cobol as the predominant paradigm), then every OO language should have type classes! It’s sort of folklore knowledge that C#/Java-like interfaces are castrated type classes. Also, Klaus Ostermann and I had alluded to some deeper correspondences in our GPCE paper. However, a real transposition of type classes to say Java was still missing. (I couldn’t find anyone who wanted to work with me on this topic for C#; too bad).
Thanks to Peter Thiemann and Stefan Wehr, I had the opportunity to participate in a language-design project: JavaGI — Java 1.5 with generalized interfaces inspired by type classes in Haskell. I like the conclusion of our paper more than the abstract, so below it goes. Please drop me an email if you have any comments; the paper is in draft status; so all feedback is appreciated and considered for the final version some day.
We have described JavaGI, a language that generalizes Java’s interfaces in various dimensions that enable clearer program designs, stronger static typing, and extra forms of software extension and integration. To this end, we have basically transposed Haskell’s type classes. This process has clarified that type classes combined with existentials subsume Java-like interfaces. We have watched out for feature interactions with existing uses of interfaces, subtyping, and subclassing. In particular, JavaGI is the first satisfactory example of a language where type classes (interfaces) and subtyping coexist. In this language-design process, we realized that a convenient form of existential quantification needs to become part of the extended Java type system. All of the scenarios that JavaGI can handle have been previously identified in other work; however, using separate language extensions with unclear interaction. There is no single proposal that would match the expressiveness of JavaGI’s interfaces + existentials. Hence, we do not apply for an originality award but we hope to score with the uniformity and simplicity of generalized interfaces.