title: Subtype polymorphism in Haskell
body: <p>Building a hierarchy of GUI widget classes is pretty much a standard exercise in object-oriented programming. You have some sort of abstract <code>Widget</code> class, with an abstract subclass for widgets that can contain other widgets, and then you have a profusion of further abstract classes for widgets that support textual display, widgets that support being the input focus, widgets that have a boolean state, right down to actual concrete classes such as buttons, sliders, scrollbars, check boxes, etc.</p>
  
  <p>My question is: What is the best way to do this in Haskell?</p>
  
  <p>There are a number of things that make building a Haskell GUI difficult, but are <em>not</em> part of my question. Doing interactive I/O is mildly tricky in Haskell. Implementing a GUI almost always means writing a wrapper to an extremely low-level C or C++ library. And people writing such wrappers tend to copy the existing API verbatim (presumably so anybody who knows the wrapped library will feel at home). These problems do not interest me at the moment. I'm interested purely in how best to model subtype polymorphism in Haskell.</p>
  
  <p>What kind of properties would we want from our hypothetical GUI library? Well, we want it to be possible to add new widget types at any time. (In other words, a closed set of possible widgets is no good.) We want to minimise code duplication. (There are <em>a lot</em> of widget types!) Ideally we want to be able to stipulate one specific widget type when necessary, but also to be able to handle collections of <em>any</em> widget type if needed.</p>
  
  <p>All of the above is of course trivial in any self-respecting OO language. But what is the best way to do this in Haskell? I can think of several approaches, but I'm not sure which one would be "best".</p>