Software Extension and Integration with Type Classes

Software Extension and Integration with Type Classes. Ralf Lämmel and Klaus Ostermann.

The abilities to extend a software module and to integrate a software module into an existing software system without changing existing source code are fundamental challenges in software engineering and programming-language design. We show that these challenges can be tackled, at the level of language expressiveness, by using the language concept of type classes, as it is available in the functional programming language Haskell. A detailed comparison with related work shows that type classes provide a powerful framework in which solutions to known software extension and integration problems can be provided. We also pinpoint several limitations of type classes in this context.

We've had a number of papers lately with solutions to the expression problem and related extensibility challenges, using various techniques in various languages. Here's one exploring the expressiveness of Haskell's type classes.

It's extremely instructive to compare different approaches to these now-standard problems, and in fact I wonder whether this would make an ineresting approach to a programming languages survey course: In CS 3xx we explore and compare a number of programming languages by exploring idiomatic solutions to standard software engineering challenges.

The authors are looking for comments on this draft for a few more days.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Typeclasses

Focusing on typeclasses rather than the expression problem here; as many have no doubt gathered there are a variety of, often surprising, applications of typeclasses. I made the page UnderestimatedTypeClasses, over a year ago, that lists many such applications. Unfortunately, I haven't been updating it and so it is missing even more new ones. As is occasionally mentioned, while purity and laziness are good reasons to learn Haskell (i.e. things about Haskell that are different from other languages), typeclasses themselves are reason alone. The only language I'm aware of that also supports typeclasses is Mercury, which, even then, does not support constructor classes (a very significant limitation) if its Haskell comparison is up-to-date.

Don't forget Clean

The Clean language also supports type classes.

SE

In CS 3xx we explore and compare a number of programming languages by exploring idiomatic solutions to standard software engineering challenges.

That's roughly how you should teach SE today. I don't think the important part is to focus on the languages (i.e., a language survey course), but rather on the techniques (i.e., a survey of techniques, some available in multiple languages in multiple ways). In fact, that's roughly what I attempt to do when I introduce students to things like parameterized modules, inheritance etc. I hope others do the same.

More interesting is the specific problem under discussion here (expression problem and related extensibility challenges). This should get a chapter if/when I write my SE textbook one of those days...

Type traits or the Strategy pattern and dictionary translation

Just a quick comment. I just read section 2 of the draft article and, well, it makes me wonder whether the authors are aware of techniques such as traits (in C++) or the Strategy pattern in GoF? An example of a trait or the Strategy pattern in the Java API would be Comparator. What I'm suggesting here is that a similar solution as (in section 2) with type classes can be achieved with type traits and the Strategy pattern in OO languages. Indeed, it seems to me that the use of traits or the Strategy pattern correspond to the dictionary-translation implementation of type classes.