Subtype polymorphism in Haskell

Question

Building a hierarchy of GUI widget classes is pretty much a standard exercise in object-oriented programming. You have some sort of abstract Widget class, with an a

Answer 1

To understand what OOP, such as subtype polymorphism, can be done in Haskell you can look at OOHaskell. This reproduces the semantics of a variety of powerful OOP type systems, keeping most type inference. The actual data encoding was not being optimized, but I suspect type families might allow better presentations.

Modelling the interface hierarchy (e.g. Widget) can be done with type classes. Adding new instances is possible and so the set of concrete widgets is open. If you want a specific list of possible widgets then GADTs can be a succinct solution.

The special operation with subclasses is upcasting and downcasting.

This is first needed to have a collection of Widgets, and usual result is to use existential types. There are other interesting solutions if you read all the bits of the HList library. The upcasting is fairly easy and the compiler can be certain that all casts are valid at compilation time. The downcasting is inherently dynamic and requires some run-time type information support, usually Data.Typeable. Given something like Typeable the downcasting is just another type class, with the result wrapped in Maybe to indicate failure.

There is boilerplate associated with most of this, but QuasiQuoting and Templating can reduce this. The type inference can still largely work.

I have not explored the new Constraint kinds and types, but they may augment the existential solution to upcasting and downcasting.