[GUI] inheritance using type classes

[Daan Leijen]

Hi all,

(Sorry for the long mail and pollution of the mailing list, but
I would like to say a bit more about the trade-offs when modelling 
inheritance using type classes versus phantom types.)

Alle 22:18, martedì 16 settembre 2003, Daan Leijen ha scritto:
> This is a devious thing to do, but totally unavoidable given the way
> I model inheritance with phantom types. I have considered using 
> type classes to model the inheritance but that leads to a) other 
> dependencies on extensions, b) hard to understand error messages, 
> and c) a much more complex model. (See Andre Pang's master thesis 
> for a ingenious way to model full inheritance)

Inheritance can be modelled fully with type classes but leads to a 
complicated system that depends on many extensions to work in practice 
(like MPTC and functional dependencies). That is why I used phantom 
types to model inheritance in wxHaskell -- simplicity! 

However, I just realized that with the proper restrictions, there also 
exists a reasonably simple inheritance model using just haskell98 type 
classes. (There is a catch of course, but more on that later). Most 
complications normally arise as we also want to model object methods 
that are overloaded on their type signatures (like java and c++ 
allow). For wxHaskell though, we don't need to do this, as no such 
overloading occurs.

This allows us to "lift" the object methods out of a haskell class 
declaration and to model only the inheritance relationship with type 
classes.

Here is how it works concretely: In the Haskell world, each object is 
in the end represented by a pointer, say "Addr". So, we can make a 
class that returns this pointer for each haskell object.

> class Object object where
>   self :: object -> Addr

Now, suppose we have a "Window" class with a creation method and show 
method. First, we create a type that represents this class in Haskell, 
and we'll call "WindowObject".

> newtype WindowObject  = WindowObject Addr
>
> windowCreate :: IO WindowObject
> windowCreate = do{ addr <- primWindowCreate;
                     return (WindowObject addr) }

Next, we model the inheritance using a (phantom) type class and 
instance.

> class Object window => Window window
>
> instance Object WindowObject where
>   self (WindowObject addr) = addr
>
> instance Window WindowObject

The "show" method is written as:

> windowShow :: Window window => window -> IO ()
> windowShow window
>    = primWindowShow (self window)

Note that the inferred type is "Object w => w -> IO ()", but we want 
to constrain it by hand to windows only. Furthermore, we don't use a 
"WindowObject" as the argument, as we want to be able to pass *any* 
kind of Window to this function.

For example, a Button object derives from a Control, that in turn 
derives from the Window class:

> newtype ButtonObject  = ButtonObject Addr
>
> class Control button => Button button
>
> instance Object ButtonObject where
>   self (ButtonObject addr) = addr
>
> instance Window ButtonObject
> instance Control ButtonObject
> instance Button ButtonObject
>
> buttonCreate :: IO ButtonObject
> ...
> buttonSetLabel :: Button button => button -> String -> IO ()
> ...

Clearly, we can now use the "windowShow" method on "ButtonObjects" too 
-- exactly what we want. Furthermore, we can also downcast objects:

> downcastWindow :: Window window => window -> WindowObject
> downcastWindow window  = WindowObject (self window)

Up till now, there is not much advantage with regard to using phantom 
types: the effect is the same and the types with overloading are bit 
more complicated. However, there may be some other advantages.

Suppose I want to create more abstraction and use a type class 
"Textual" that retrieves some text from an object. 

> class Textual w where
>   text :: w -> IO String

We use a type class here since we want to use "text" on both the 
objects imported from the library, but also on user defined data 
types. Suppose that every window has "windowGetLabel" method. This 
means that we define "Textual" for any kind of window in one go:

> instance Window w => Textual w where
>   text = windowGetLabel

I use the same trick when using phantom types (the free "a" type 
variable encodes the "any kind of window"):

> instance Textual (Window a) where
>   text = windowGetLabel

The attentative reader now notices that both instance declarations are 
illegal in haskell98 and require the "allow undecidable instances" 
flag (i.e. the context reducer could loop). Furthermore, the latter 
also uses a type synonym but that is easy to circumvent (Window a == 
Ptr (CWxObject (CEvtHandler (CWindow a)))

However, there is an important difference -- If we really want, we 
could replace the first instance declaration with a specific instance 
declaration for each kind of object:

> instance Textual WindowObject
> instance Textual ControlObject
> instance Textual ButtonObject
> ....

This would be haskell98 compliant. Unfortunately, no such thing can be 
done with phantom types (as the instance heads remain "complex", even 
though they are always "decidable" (i.e. reduce without looping)).

Given the more complex type signatures and error messages, I 
personally find the price too high. Especially since in the wxhaskell 
case the amount of instance declarations would rise from a single 
declaration to hundreds of instance declarations for each kind of 
widget. But maybe this gives at least some more insight in the 
different trade-offs that we can make.

All the best,
 Daaan.