This is the first of three lectures on integrating domain-specific languages with general-purpose programming languages. In particular, SQL for database queries.
Read the rest of this entry »
This block of four lectures are arranged around some features of the Haskell type system. They aren’t just specific to Haskell, though: several appear in other languages too, and they all address general programming issues. Haskell does make a convenient setting to examine them, as the language development has a strong connection to programming language research, and it is sufficiently popular that there is a wide array of commentary out in the blogosphere on how well that works out.
The lecture covered background on type systems in programming languages, what they are used for and how they might be tricky. The interaction of types, subtypes and inheritance in object-oriented languages is an example of this, which Java’s covariant subtyping of arrays conveniently demonstrates. Haskell’s type classes tackle many of the same issues, but from a substantially different direction. Arising originally from attempts to rationalise overloading of basic operations like equality, type classes have grown far beyond this to serve as a tool for imaginatively building a range of high-level programming abstractions.
The presentation itself was somewhat distorted by the non-operation of the projector screen. My apologies, I’ll report it and see if things go better on Thursday.
For Thursday’s lecture, read the following paper and set of slides.
- Philip Wadler and Stephen Blott. How to make ad-hoc polymorphism less ad-hoc. In Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages, pages 60–76. ACM Press, 1989.
- Simon Peyton Jones. Wearing the hair shirt: a retrospective on Haskell. Invited talk at POPL 2003.
For further reading, see the lecture slides. These carry a range of embedded hyperlinks to references, research papers, and background material on the various examples.
In the spirit of the diagram from Cook’s paper, can anyone identify a pair of classes A and B, in any OO language or library, where A is (or should be) a subtype of B, while B inherits (or ought to, for code reuse) from A?