%
% Author   : Andr\'e T. H. Pang
%            (ab)using LaTeX source from Don Stewart's stgjvm.tex
%
% Created  : Sun May 25 00:22:05 EST 2003
% Last Mod : 
%

% TODO:
%
% search for ?? in pdf to cross-check list refs
% search for allow

\documentclass[10pt,a4paper,titlepage,oneside]{book}

\usepackage[hyper]{listings}
\usepackage{cite}
\usepackage{url}
%\usepackage{times} % for the printed version
\usepackage{fancyhdr}
%\usepackage[all,light,outline]{draftcopy}
\usepackage[dvips]{graphicx}
\usepackage{ifthen}
%\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{footmisc} % for \footref: reference footnotes as labels


\usepackage[colorlinks=true,
  linkcolor=black,
  anchorcolor=blue,
  citecolor=blue,
  urlcolor=blue
  dvipdfm=true,
  urlcolor=blue]{hyperref}

%\DeclareGraphicsExtensions{.pdf}

% fancy headers
\pagestyle{fancy}
\renewcommand{\chaptermark}[1]{\markboth{#1}{}}
\renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}}
\fancyhf{}
\fancyhead[LE,RO]{\bfseries\thepage}
\fancyhead[LO]{\bfseries\rightmark}
\fancyhead[RE]{\bfseries\leftmark}
\renewcommand{\headrulewidth}{0.5pt}
\renewcommand{\footrulewidth}{0pt}
\addtolength{\headheight}{0.5pt}
\fancypagestyle{plain}{
    \fancyhead{}
    \renewcommand{\headrulewidth}{0pt}
}

\newcommand{\mocha}{Moch$\Lambda$}

\newcommand{\derives}{\mbox{$\rightarrow$}}
\newcommand{\orderives}{\mbox{$\mid$}}
\newcommand{\te}[1]{{\tt{#1}}}
\newcommand{\fixme}[1]{{(\texttt{\textbf{FIXME}}: #1)}}
\newcommand{\ctohs}{C$\to$Haskell}

%
% Haskell code listings
%

\lstset{
	language=Haskell,
	basicstyle=\sf,
	floatplacement=htbp,
	frame=tblr,
	fontadjust=false,
	flexiblecolumns=true,
	xleftmargin=0.2in,
	xrightmargin=0.2in,
	framextopmargin=2.0pt,
	framexbottommargin=2.0pt,
	framexleftmargin=2.0pt,
	framexrightmargin=2.0pt,
	aboveskip=\medskipamount,
	belowskip=\medskipamount,
	tabsize=4,
	breaklines=true
}

\newcommand{\inlinec}{\lstinline[language=C, frame=none]}
\newcommand{\inlinej}{\lstinline[language=Java, frame=none]}
%\newcommand{\inline}{\lstinline[frame=none]}
\newcommand{\inline}{\textsf}

% prettifying Haskell output
\lstset{
	literate=
	{->}{$\to$ }{2}
	{=>}{$\Rightarrow$ }{2}
	{<-}{$\leftarrow$ }{2}
	% {\\}{$\lambda$}{1} % doesn't work when \ is in a string :(
	{>>=}{$\gg=$ }{3}
	{>=}{$\geq$ }{1}
	{/=}{$\ne$ }{1}
	{...}{\ldots }{3}
}

\newcommand{\lstref}[1]{Listing \ref{#1}}
\newcommand{\figref}[1]{Figure \ref{#1}}
\newcommand{\sectref}[1]{Section \ref{#1}}

\newcommand{\lstrefpage}[1]{Listing \ref{#1}\ifthenelse{\value{page}=\pageref{#1}}{}{ (page \pageref{#1})}}

\newcommand{\figrefpage}[1]{Figure \ref{#1}\ifthenelse{\value{page}=\pageref{#1}}{}{ (page \pageref{#1})}}

\newcommand{\sectrefpage}[1]{Section \ref{#1}\ifthenelse{\value{page}=\pageref{#1}}{}{ (page \pageref{#1})}}

%\frenchspacing

\begin{document}

%%%%%%%%%%%%%%%%%%%%%
%%% title page
%%%%%%%%%%%%%%%%%%%%%

\thispagestyle{empty}
\begin{titlepage}

\begin{center}
    % \vspace*{\stretch{1}}
    {\textsc {\LARGE {\textbf The University of New South Wales \\}}}
    \vspace{.2in}
    {\textsc {\large {\textbf School of Computer Science and Engineering \\}}}
    \vspace{1.5in}
    {\Huge {\bf Binding Haskell to Object-Oriented Component Systems via Reflection\\}}
    \vspace{1.5in}
    {\Large {\bf Andr\'e T. H. Pang\\}}
    \medskip
    {\large {B. Sc (Computer Science \& Psychology) Honours Thesis\\}}
    \medskip
    {\large {June 2003\\}}
    \vspace{1.5in}
    {\large 
        \begin{tabular}{rl}
            Supervisor:& Dr. Manuel Chakravarty\\
              Assessor:& Dr. Kai Engelhardt\\
        \end{tabular}
    }
\end{center}

\vspace{\stretch{1}}

\end{titlepage}

%%%%%%%%%%%%%%%%%%%%%
%%% abstract
%%%%%%%%%%%%%%%%%%%%%

\newpage
\frontmatter
\thispagestyle{empty}
\vspace*{\stretch{1}}
\begin{center}
{\textbf {\Large Abstract }}
\end{center}

A universal framework is described to interface Haskell to a component system or object-oriented programming language with reflection capabilities.  Techniques are shown which enable modelling an object-oriented class hierarchy, including multiple inheritance and class objects, in Haskell.  Template Haskell is used as a basis to write an interface generator, which uses the reflective capabilities of the targeted component system to automatically derive and create a Haskell interface for the components' APIs.

A low-level communications library is designed which enables sending messages to components, and a high-level messaging API is layered on top of the library to present a convenient, elegant interface for a Haskell programmer to interact with components.  Techniques are given to enable exception marshalling between the component system and Haskell, to perform memory management of foreign components in the Haskell system, and to write a component in Haskell.  A Haskell to Objective-C binding named \mocha{} has been written, to show that these ideas are practical and can be implemented.

\vspace{\stretch{1}}

%%%%%%%%%%%%%%%%%%%%%
\chapter*{Acknowledgements}
%%%%%%%%%%%%%%%%%%%%%

The problem with acknowledgements is that

\begin{displaymath}
\exists a\Rightarrow person(a) \wedge unacknowledged(a)
\end{displaymath}

Nevertheless, I am indebted to far too many people to not express not my gratitude at all.  This thesis was more than a one-man show.\\


Immense thanks must go to my comrades in the Programming Languages and Systems research group at UNSW, especially Sean Seefried, Gabi Keller and Don Stewart, who always found the time to help me with obscure questions, on topics ranging from computer science to the meaning of life.  (Try as they might, I still believe they're two different things.)\\


Thanks to all the helpful people in the Haskell community, who produce the wonderful compilers and tools that we use, and all the knowledgeable, friendly folk on the mailing lists and $\#$haskell for answering questions which I had.\\


To Jeffrey Lim, whose friendship and heart is only rivalled by his incredible programming abilities.  Any good knowledge I have about program design, I learnt from you.  Thanks.\\


To my supervisor, Manuel Chakravarty, who introduced me to the wonderful world of functional programming, and guided me through the maze of computer science and University in a way that nobody else could have done---all while being a fantastic friend.  I hope this thesis makes you proud.\\


To my family, who always support me and understand me no matter how much sleep I've not had.  Thank you for always being there.\\


To Michelle, for just being who you are.

%%% TOC
\tableofcontents

\mainmatter

%%%%%%%%%%%%%%%%%%%%%
\chapter{Introduction \& Background}
%%%%%%%%%%%%%%%%%%%%%

\section{Haskell}

Haskell is a purely functional programming language.  It has many features which make it desirable to use, such as strong, static typing with a type inference engine, parameterised data types, ad-hoc and parametric polymorphism, lazy evaluation, higher-order functions, and built-in memory management.  Haskell offers full-fledged IO via monads, and a standardised \emph{Foreign Function Interface}\cite{CHAK03} (\emph{FFI}) to interact with the operating system and other languages.

\section{Object-Oriented Programming}

The object-oriented programming paradigm is based around the idea of an \emph{object}. An object is a collection of data and functions which operate on that data, merged into a single entity.  The object's internal data (known as \emph{instance variables} or \emph{fields}) can typically only be manipulated through the functions which the object exposes (called \emph{methods}).  This ensures that details of an object's implementation are hidden behind the interface offered by the object's methods.  Thus, objects provide a means of \emph{data encapsulation}.  Calling a method of an object is usually known as \emph{invoking} a method, or \emph{sending a message} to the object (where the method to invoke is part of the message's payload).

Objects are categorised into various \emph{classes}.  A class is a specification for what fields and methods an object should contain.  Using classes, object-oriented systems offer a feature known as \emph{inheritance}: classes can \emph{inherit} or \emph{subclass} other classes.  All the fields and methods of the inherited class (also called the \emph{superclass}) become part of the specification of the \emph{subclass}.  Objects which are instantiated from a subclass are treated as belonging to the same category as an object instantiated from the superclass; i.e.\ from the compiler's point of view, a subclass can masquerade as the same \emph{type} of the superclass (but not vice versa).  Type inheritance is more formally known as \emph{subtyping}.

Examples of object-oriented programming languages include C++, Java, Smalltalk, and Objective-C.

\section{Component Systems}

\emph{Component systems} have been evangelised as a way of building systems through self-contained entities known as \emph{components}. Components, like objects, are required to hide their implementation from their interface, and also offer a standard protocol for performing a component's actions and communicating between components.

Components therefore share much similarity with object-oriented programming.  Both systems are based around the idea of self-contained entities with data encapsulation, and both systems offer methods that can be invoked by other objects and components, with a standard way of invoking those services.  Examples of component systems include CORBA, (D)COM and Enterprise Javabeans (J2EE).

While components and objects are similar, they usually differ in two significant respects:

\begin{itemize}

	\item Component systems are required to offer ways to locate and communicate with other components in the system.  For example, in CORBA, a component known as an Object Request Broker (ORB) can locate a component which performs the services that another component requires, and establish communication channels between those two services.

	\item Objects are typically much more fine-grained than components.  The range of services or functionality that an object offers is usually smaller than a component.

\end{itemize}

Even with these differences, it is common to see object-oriented programming languages being used as a basis to write components because it is easy to create an object which functions as a component.  This is usually achieved by using a \emph{software adapter}, which transforms the component system's method calling convention into one which the object can understand.

Indeed, sometimes the line between object and component systems are even more blurred than outlined above.  A component system can be built from a programming language feature commonly known as \emph{reflection} or \emph{introspection}.  Reflection enables programs, at run-time, to query detailed information about objects, such as what class and superclass an object belongs to and what methods an object offers.  Reflection also usually allows a running program to create instances of or invoke methods on objects, even if the appropriate class, object and method names are not known until runtime. Reflection can therefore serve as a foundation for building a facility to locate other objects in the system, so that a programming language itself can, with little effort, be extended to become a complete component system.  Enterprise Javabeans is an example of a component system which is implemented in this manner.

For the purposes of this thesis, object-oriented languages which have reflective capabilities will be treated in the same manner as component systems.  Both systems are similar enough that they present the same challenges in integrating them with Haskell.

\section{Motivation and Overview}

Haskell has nowhere near the popularity of object-oriented programming languages and component systems.  Indeed, object-oriented languages and components serve as the foundation for many modern systems, and many frameworks, libraries and platforms use object-oriented class hierarchies to structure themselves.  There are a number of benefits to both the Haskell and object-oriented worlds if a binding could be created which enables Haskell to communicate with and act as an object or component:

\begin{itemize}

	\item Many important APIs are object-oriented.  For example, the Objective-C Cocoa framework, the Microsoft Foundation Classes, and the GTK+/QT toolkits are standard APIs which are used to develop GUI applications on the Mac OS X, Windows and UNIX platforms.  All these APIs are object-oriented, so a way for Haskell to use these frameworks in a convenient, elegant manner would enable Haskell to build sophisticated GUI applications.

	\item Component systems such as CORBA, (D)COM/OLE, Enterprise Javabeans, Bonobo and KParts are evolving into \emph{d\'e facto} ways to provide extra functionality to their respective environments.  Each component system usually provides multiple language bindings, but a Haskell binding to such systems is rare because of the difficulties faced in bridging Haskell to the component systems.

	\item Enabling Haskell to communicate with component systems opens Haskell to a far greater audience.  Authors of components and applications may turn to Haskell to build their systems if they understand that Haskell can easily interplay with component and object-oriented systems.

\end{itemize}

This thesis tackles the challenging problem of interfacing Haskell with object-oriented and component systems.  There are many problems to be solved: how can Haskell model an object-oriented class hierarchy, which includes modelling features such as class inheritance, and multiple inheritance?  Can such a model be designed while taking full advantage of Haskell's strong, static typing whenever possible?  How can Haskell invoke methods on objects, and send messages to components, again while retaining strong, static typing where appropriate?  How can a convenient messaging API be written, so that Haskell programmers who wish to interact with components can do so, in a manner as convenient as one of the component system's natively supported programming languages?  How can exceptions be marshalled from the component system to the Haskell environment, and how can Haskell's memory management be extended to support management on foreign components?

This challenges are all defined and tackled in this thesis, and not only have solutions been found to many of the problems, but a Haskell to Objective-C language binding has been written to prove that these ideas are practical and work.  This language binding, \mocha, allows Haskell to interact with the powerful \emph{Cocoa} framework written in Objective-C.  Cocoa is the primary framework used to develop applications on Mac OS X, and \mocha{} shows that binding Haskell to such a framework has great benefits.  By using \mocha{}, Haskell can be used to build full-blown graphical applications on Mac OS X, and Haskell can also be used to create objects which interact with the rest of Cocoa and the operating system.

\section{Overloaded Terminology}

The functional programming and object-oriented programming disciplines are both rich with their own terminology. Some words have conflicting meanings in the two domains: in particular, the definitions of \emph{class}, \emph{template} and \emph{overloading} should be clarified.

\subsection{Classes and Types}

A \emph{class} in object-oriented terminology is a specification of what methods and instance variables that a concrete instantiation of that class---an \emph{object}---should have.  Classes can be thought of as types, and class names are usually used as types in object-oriented languages to permit the compiler to type-check expressions.  Indeed, the analogy to a class in the Haskell world is the Haskell \emph{data type} (or simply \emph{type}), with the notable exception that Haskell does not permit subtyping.

Classes in Haskell are different entities from classes in object-oriented programming; Haskell's classes, more formally known as \emph{type classes}, serve as a form of \emph{overloading} (also known as \emph{ad-hoc polymorphism}).

\subsection{Type Classes and Overloading}

Type classes allow for a function to have different implementations, depending on the type(s) of the arguments passed to the function.  For example, the Haskell function \inline{show} can be used to display any data type as a string, as long as the data type to be displayed is an \emph{instance} of (belongs to) the \inline{Show} type class, which requires that the data type has implemented an appropriate \inline{show} function.

It is important to note that the type signature for the functions in the type class remains the same no matter how many implementations it has.  This is achieved by using \emph{constrained type variables} in the type signature for the overloaded function.  The constrained type variables represent arguments of any type which are instances of the type class.  For example, the type signature for the Haskell \inline{$>$} (greater than) function is \lstinline{Ord a => a -> a -> Bool}, which signifies that \inline{$>$} takes in two arguments of type \inline{a} which must belong to the type class \inline{Ord}, and outputs a value of type \inline{Bool}.  A compile-time error will be raised by the type checker if the constraints on the type variables are not met.

Type classes can also be \emph{subclassed}, so that any data type which belongs to the subclass also belongs to the superclass. For example, the \inline{Ord} type class specifies types which have the property of being ordered, so that one can use the comparison functions \inline{$<$} and \inline{$>$} on those types to see which of the arguments is greater or lesser.  However, for a type to be ordered, it must also be possible to define whether two values are equal: thus, the \inline{Ord} type class can \inline{subclass} the \inline{Eq} type class, so that any instances of \inline{Ord} are also required to be instances of \inline{Eq}.

Haskell's type classes are most analogous to \emph{operator overloading} in C++, although Haskell's overloading is not restricted to the standard mathematical operators.  Type classes allow a programmer to define new functions (such as \inline{show}) which can be overloaded, and specify which implementation of those functions should be chosen for particular types.

Note that this definition of overloading in Haskell is very different to the typical definition of overloading in the object-oriented world, which often refers to \emph{method overloading}.  Method overloading enables a method to have multiple type signatures, and which method is called is dependent on which type signature matches the function call.

\subsection{Parameterised Types \emph{vs.} Templates}

Haskell also supports the notion of \emph{parameterised types}: these are type definitions which contain a \emph{type variable}.  When the type is instantiated, the type variable is filled in with a concrete Haskell type, such as an \inline{Int} or a \inline{String}.  For example, a pointer in Haskell has the type \inline{Ptr a}; when an actual pointer is created, the type variable \inline{a} must be instantiated with a concrete type, so that a pointer to an \inline{Int} will have the type \inline{Ptr Int}, and a pointer to a \inline{Float} will have the type \inline{Ptr Float}.

The object-oriented programming language C++ also supports parameterised types through a mechanism called \emph{templates}.  As well as parameterised types, C++ templates are used as a form of \emph{compile-time meta-programming}.  At the time of compilation, the template generates code as its output which becomes part of the final program.

The Glasgow Haskell Compiler (\emph{GHC}) also offers meta-programming facilities via \emph{Template Haskell}.  What is important to note here is that C++ templates, while offering meta-programming, are focused on providing parameterised types to the language.  Template Haskell, on the other hand, is focused purely on meta-programming.  Parameterised types and meta-programming are two distinctly different features in Haskell, whereas they are tightly coupled in C++.





%%%%%%%%%%%%%%%%%%%%%
\chapter{Haskell vs. Component Systems}
%%%%%%%%%%%%%%%%%%%%%

\section{Integrating Haskell and Component Systems}

The challenge is to allow Haskell to communicate with component systems: Haskell programs must be able to locate and identify components, and send and receive messages to and from those components, just as any other component would be able to do.  This must be done while still maintaining an \emph{elegant} interface on the Haskell side, so that its important features such as strong type checking and its purely functional nature can still be used while interacting with components.  The interface must also be \emph{convenient} to use, so that using it in Haskell is at least as simple as using one of the component system's primary supported languages.

Ideally, Haskell should act as a first-class citizen in the component system, so that it is possible to write components or objects in Haskell and interface those Haskell-written components with the rest of the system.  Again, this must be done by using a convenient, elegant Haskell interface to write the component.

Given these defined goals of elegance and convenience, it is possible to divide the challenge of integrating Haskell with component systems into two parts:

\begin{itemize}

	\item allowing Haskell to communicate with other components or objects, and
	
	\item presenting an elegant, convenient interface on the Haskell side, so that the component system's concepts such as class inheritance can be understood and modelled on the Haskell side---with full support from the type system where appropriate.
	
\end{itemize}

At first glance, it may seem that cleanly separating the problem into these two parts is a wise idea: it should be possible to tackle each sub-problem individually.  However, it may be difficult to layer a higher-level, more convenient API on top of a more primitive communications API if the right foundations are not present in the primitive API.

For example, it is tempting to use a single type to in Haskell to represent any object or component.  This may enable a simpler design for the communications library.  However, this design decision may cause problems when attempting to model the object-oriented class hierarchy in Haskell.  In particular, it will not be possible for the type system to distinguish between different types of objects if a single type is used to represent all objects.

\section{Modelling an Object-Oriented Class Hierarchy}

Many component systems borrow concepts from object-oriented systems, such as using object-oriented classes to represent components of different types.  Some component systems even support the use of class inheritance, so that a component's interface or implementation can be based upon another component's.  If a component system's class hierarchy can be modelled via Haskell types in an isomorphic manner, this would allow Haskell to perform static, strong type checking on code which involves components.

Unfortunately, numerous problems arise from the mismatch between Haskell's type system and the type systems typically found in object-oriented languages:

\begin{itemize}

	\item Haskell lacks a defining feature of object-oriented systems: it does not have subtyping (inheritance).
	
	\item A subclass may inherit from multiple superclasses.  It may only be allowed to inherit the interface of those superclasses (e.g.\ Java, C$^{\#}$, Objective-C), or it may inherit both the interface and implementations from its superclasses (e.g.\ C++).
	
	\item In some object-oriented systems (e.g.\ Java, Smalltalk, Objective-C), defining a class has a dual purpose: it creates a new type with the same name of that class, and it also creates an instantiated object known as a \emph{class object}.  This instantiated object is typically used as a \emph{factory object}: to create an instance object which belongs to a particular class, you invoke a method of that class's factory object (e.g.\ often named \inline{alloc} or \inline{new}) which creates the instance for you.
	
\end{itemize}

The aim is to model these features of an object-oriented class hierarchy in Haskell, and do so in a manner which requires minimum extension to the language.  The type checker must still be able to infer the types of objects and accurately type check code which uses objects---including any functions responsible for communicating with the component system.

There is also the non-trivial problem of performing the actual modelling.  It is unacceptable for a programmer to tediously write the declarations required to encode a class hierarchy: the Java API's prototype declarations span hundreds of pages.  Automating the transformation of the class hierarchy into Haskell must be possible.
 
\section{Communication with Components}

For Haskell to \emph{communicate} with components, it must be able to send messages to and receive \emph{messages} from a component.  There are several problems involved with communication:

\begin{itemize}

	\item How is it possible to build a message in Haskell which can then be sent to other components?
	
	\item How do we ensure that the information in each message follows the component's messaging protocol; e.g.\ that each item in the message has the proper type and alignment required by the receiving component?

	\item How can Haskell perform the actual operation of sending and receiving messages to and from a component?
	
	\item If sending a message to a component results in the component \emph{replying} to us with a return value, how can the replied data, and its type, be obtained?
	
	\item Is it possible for the communications interface to \emph{marshal} values between the Haskell environment and the component system, so that native Haskell data types can be understood by the component system and vice versa?
	
	\item How can Haskell \emph{receive} messages from the component system, i.e. how can a component be written in Haskell?
	
\end{itemize}

\section{Exception Marshalling}

\emph{Exceptions} are pre-defined events in program which indicate exceptional conditions, such as a division by zero error.  They can potentially change the flow of control in a program.  When Haskell is interacting with a component system, an exception may be \emph{thrown} (or \emph{raised}) in the component system, which should then be \emph{caught} and \emph{marshalled} to the Haskell environment, so that Haskell code can take an appropriate action to handle the exceptional condition.  How can exceptions be marshalled to the Haskell environment, and how can a communications framework be designed to correctly catch and marshal exceptions?

\section{Memory Management}

Haskell features automatic memory management by using a \emph{garbage collector}, so that a Haskell programmer never has to worry about allocating and deallocating memory for expressions.  If Haskell is to interact with a component system, the automatic memory management that a programmer is used to in the Haskell environment should also be able to manage any foreign components.  How can Haskell's memory management system be extended to support foreign components?  It is always possible or necessary to perform such memory management when interfacing with component systems?

\section{Summary of problems}

There are a number of challenges involved in interfacing Haskell to a component system.  It may be simple to enable Haskell to communicate with a component system, but presenting a convenient, elegant Haskell API for such communication is far harder.  The main problem areas include:

\begin{itemize}

	\item \emph{Modelling an object-oriented class hierarchy} in Haskell while retaining strong, static typing where appropriate.  This may include modelling subtyping, multiple inheritance and class objects, and also involves generating the a Haskell API to use any desired components.
	
	\item \emph{Communicating with components} by building and sending messages and retrieving message replies---with full type checking and type inference.  Writing components in Haskell and enabling those components to receive messages from the component system should also be possible.
	
	\item \emph{Exception marshalling}: if sending a message to the component system results in an exception being thrown, it should be possible for the Haskell environment to catch those exceptions and take appropriate action.
	
	\item Automatic \emph{memory management} of any components which the Haskell environment interacts with.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Modelling a Class Hierarchy in Haskell}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%

For Haskell to communicate with component systems, it would be ideal if there was a way to model the component system's class hierarchy and types in Haskell.  Without Haskell knowing about the component system's class hierarchy, two of Haskell's most defining features---strong typing and type inference---would not be used to their full potential on Haskell code which uses with components.

Encoding a class hierarchy in Haskell is a non-trivial problem due to the mismatch between its type system and the type systems typically used by component systems and object-oriented languages.  Nevertheless, there are several techniques that can be used which enable Haskell's type system to accurately model the typing used by object-oriented languages while still allowing strong typing and type inference.

\subsection{Phantom types}

One method of modelling an object-oriented class hierarchy with inheritance is using \emph{phantom types}: a phantom type is a parameterised type where the parameter does not occur in the type constructor definition; in \lstinline{data Foo a = Foo}, for example, \inline{a} is a phantom type.  The phantom type can be used by the type system to guarantee that any instances of that type are well-formed.  In this case, the type's parameter can be used to model subtyping, to a limited extent, in the type system.  For example, \lstref{listing:superSubJava} shows a Java class declaration for two classes \inline{Super} and \inline{Sub}; a Haskell encoding of the class hierarchy using phantom types is shown in \lstref{listing:superSubHaskell}.

\begin{lstlisting}[float, language=Java, caption=A superclass and subclass in Java, label=listing:superSubJava]
class Super { ... }
class Sub extends Super { ... }
\end{lstlisting}

\begin{lstlisting}[float, caption={A superclass and subclass in Haskell, modelled with phantom types}, label=listing:superSubHaskell]
data SuperT a = SuperT
type Super a = SuperT a

data SubT a = SubT
type Sub a = Super (SubT a)
\end{lstlisting}

The type \inline{Super ()} can then be used whenever an instance of the \inline{Super} object-oriented class is required, but none of its subclasses would be accepted if this type is used.  To accept any instance of the \inline{Super} class, including any of its subclasses,  the type \lstinline{Super a} is used.  This technique has been used in a number of previous approaches to bind Haskell to component systems\cite{FINN99, PEYT98, FINN00}.  Its main draw-card is that it was one of the first ways to model class inheritance in Haskell, while giving the type checker enough information about the types so that it could correctly reject cases where the type of an expression is not a subclass of the superclass which was required.  This use of phantom types therefore enabled the type system to correctly, statically and strongly type check class inheritance trees.

However, using phantom types has two major disadvantages:

\begin{itemize}

	\item \emph{Long type names}.  For APIs which use inheritance extensively, type names can become very long, which can result in the type checker outputting error messages which are hard to decipher.
		
	\item \emph{Single-inheritance only}.  Phantom types cannot model an object-oriented class hierarchy which uses multiple inheritance, regardless of whether the multiple inheritance only allows interface inheritance (e.g.\ Java, C$^{\#}$) or both interface and implementation inheritance (e.g.\ C++).  Neither of these scenarios can be modelled using phantom types, since a subclass can only inherit from one superclass.
	
\end{itemize}

Since many component systems use multiple interface inheritance, phantom types cannot be the only method of modelling inheritance in Haskell.

\subsection{Representing multiple inheritance via type classes}

In Lambada\cite{FINN00}, a Haskell to Java language binding, Finne and Meijer show that type classes can be used to augment phantom types, so that multiple inheritance in object-oriented systems can be properly modelled in Haskell.  Thus, if the class \inline{Sub} inherits from two Java interfaces \inline{AnInterface} and \inline{AnotherInterface} (as shown in \lstref{listing:javaMultipleInheritance} and visualised in \figref{fig:JavaClassHierarchyExample}), one would simply augment the Haskell code in \lstrefpage{listing:superSubHaskell} with the code shown in \lstref{listing:phantomWithTypeClasses} to allow the type system to represent this inheritance.

\begin{lstlisting}[float, language=Java, caption=Java class hierarchy with multiple inheritance, label=listing:javaMultipleInheritance]
class Super { ... }

interface AnInterface { ... }

interface AnotherInterface { ... }

class Sub extends Super
	implements AnInterface, AnotherInterface { ... }
\end{lstlisting}

\begin{figure}[htbp]
\centering
\includegraphics{JavaClassHierarchyExample}
\caption{Visualisation of a Java class hierarchy with multiple inheritance.  Ellipses with solid outlines represent classes, and ellipses with dashed outlines represent interfaces.}
\label{fig:JavaClassHierarchyExample}
\end{figure}

\begin{lstlisting}[float, caption=Phantom types augmented by type classes can model multiple inheritance, label=listing:phantomWithTypeClasses]
class AnInterface i
class AnotherInterface i

instance AnInterface (Sub a)
instance AnotherInterface (Sub a)
\end{lstlisting}

A method which is part of the interface declaration simply uses the type variable constraint as part of its type signature.  The function will then accept objects only if they implement (inherit from) that interface.  For example, the type signature for a function \inline{foo} which requires a parameter that implements \inline{AnInterface} would have the type signature \lstinline{foo :: AnInterface a => a -> ...}.  Thus, both phantom types and type classes are used here to model a class hierarchy.  While this technique still suffers from the problems of hard-to-read type errors and long type names, at least it is possible to model multiple inheritance, which is a big step forward.

\subsection{Moving on from phantom types}

Shields and Peyton Jones\cite{SHIE01} go one step further with type classes: they propose a way to use only type classes and types to model an object-oriented class hierarchy, thus not requiring phantom types at all.  To model the Java class hierarchy presented in \lstrefpage{listing:javaMultipleInheritance} (visualised in \figref{fig:JavaClassHierarchyExample} on page \pageref{fig:JavaClassHierarchyExample}), the Haskell code in \lstref{listing:typeClassesMultipleInheritance} (visualised in \figref{fig:HaskellClassHierarchyExample}) can be used.

\begin{lstlisting}[float, caption=Using only type classes to model multiple inheritance, label=listing:typeClassesMultipleInheritance]
class Super c
data SuperInstance -- some opaque type
instance SuperInstance Super

class AnInterface c
data AnInterfaceInstance
instance AnInterface AnInterfaceInstance

class AnotherInterface c
data AnotherInterfaceInstance
instance AnotherInterface AnotherInterface

class Sub
data SubInstance
instance Super SubInstance
instance AnInterface SubInstance
instance AnotherInterface SubInstance
\end{lstlisting}

\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{HaskellClassHierarchyExample.eps}
\caption{Visualisation of a class hierarchy with multiple inheritance using Haskell type classes.  Ellipses with solid outlines represent data types, and ellipses with dashed outlines represent type classes.}
\label{fig:HaskellClassHierarchyExample}
\end{figure}

The type signature for a function \inline{foo} which requires an argument that is an exact instance of the class \inline{Super} would look like
\lstinline{foo :: SuperInstance -> ...}.  This would not allow any subclasses of \inline{Super} to be used as an argument to the function.  To allow subclasses of \inline{Super} to be passed to the function, the type class \inline{Super} is used as a type variable constraint.  This is the same technique used by Finne and Meijer\cite{FINN00} to implement Java interface inheritance in Lambada: the function's type signature would be 
\lstinline{foo :: Super a => a -> ...}.

This use of only type classes to encode inheritance has several advantages over using phantom types:

\begin{itemize}

	\item The type checker can give more readable error messages if it detects a type error.
	
	\item It is more elegant than using phantom types, and is more easily understood.  Haskell programmers already know that type classes can be subclassed: it is a small knowledge leap for them to understand that the same system can also be used to model object-oriented subclassing, compared to explaining how phantom types are used to model subclassing.  (Why learn two methodologies when one will suffice?)

\end{itemize}

While this scheme still has limitations (e.g. it cannot model \emph{covariant result types}), it is sufficient to model the typical class inheritance hierarchies used by the vast majority of component systems.

For all its advantages, using type classes to model inheritance has one drawback compared with phantom types: the type signature of a function that uses subclasses isn't quite as elegant as its equivalent using phantom types.  If phantom types are used, one could write \lstinline{foo :: Super a -> ...} for a type signature that accepts an argument which belongs to a class or subclass of \inline{Super}; instead of that, the type signature is now  \lstinline{foo :: Super a => a -> ...}, which is more cumbersome.

\bigskip

For binding Haskell to component systems, the approach advocated by Shields and Peyton Jones\cite{SHIE01}---using a type class \& data type per object-oriented class---is sufficient to model an object-oriented class hierarchy, and works well.  It is capable of modelling multiple inheritance without difficulty, and is also reasonably elegant.

\section{Automatic class hierarchy generation}

The majority of language binding tools come with a program to automate the process of making the desired component system's API functions available to the language we wish to bind to.  This program is called an \emph{interface generator}.

Current Haskell language binding tools\footnote{\url{http://www.haskell.org/libraries/\#interfacing}} typically use these to model the target API in Haskell.  For example, the Gtk+HS\cite{GTKH} project, which binds Haskell to the open-source GUI toolkit GTK+, relies on the \ctohs\cite{C2HS} interface generator to model GTK+'s object-oriented class hierarchy in Haskell.  \ctohs{} acts a as a pre-processor: it reads in C header files along with specially marked up Haskell modules, and writes out normal Haskell modules which then contain the Haskell mapping of the C API.  While this is a perfectly fine way of producing an API binding to a foreign language, it would be more convenient this pre-processing stage can be eliminated.

\subsection{Meta-programming the interface generator}

The introduction of version 6.0 of the Glorious Glasgow Haskell Compiler presents a powerful new idea which we can use to eliminate this pre-processing stage: \emph{Template Haskell}.  Template Haskell is a form of \emph{compile-time meta-programming}.  Meta-programming is writing a program which generates programs; compile-time meta-programming allows this code generation to happen at compile-time.  As compilation happens, the compiler can \emph{execute} user-written code, to produce the final code that is then placed into the resulting program.  Template Haskell can be thought of as a powerful macro system, or, to quote from the original Template Haskell paper by Sheard and Peyton Jones\cite{SHEA02}, Template Haskell ``allow[s] programmers to \emph{compute} part of their program rather than \emph{write} them, and to do so seamlessly and conveniently.'' (Emphasis in original.)

Template Haskell gives the programmer data types which represent Haskell syntax; for example, a function may output a value of a type \inline{Exp}, which represents a Haskell expression, or it may output a value of type \inline{Dec}, which represents a Haskell declaration.  Values of these syntax data types are called \emph{templates}, and can be executed at compile-time at various \emph{splice points} in the program, so that template expressions and template declarations are evaluated at these splice points, just as if the spliced code were written there by the programmer instead of being generated by the templates.  Since functions which generate templates are treated as normal functions, they can be called with parameters in splice points and be given customised data structures just as any normal function would.  This enables generation of different templates, depending on what parameters were given to the template-generating function.

\lstref{listing:printf} shows how to write the classic C \inline{printf} function in Template Haskell, and how to use the \inline{printf} template.

\begin{lstlisting}[float, caption={Implementing and using \inline{printf} in Template Haskell}, label=listing:printf]
-- works with %d and %s
data Format = D | S | Literal String
	deriving (Show)

parse :: String -> [Format]
parse "" = []
parse ('%':'d':xs) = D:(parse xs)
parse ('%':'s':xs) = S:(parse xs)
parse s = Literal upToAPercent:(parse afterPercent)
	where
		upToAPercent = takeWhile (/= '%') s
		afterPercent = dropWhile (/= '%') s

gen :: [Format] -> Expr -> Expr
gen [] x = x
gen (D:xs) x = [| \n -> $(gen xs [| $x ++ show n |]) |]
gen (S:xs) x = [| \s -> $(gen xs [| $x ++ s |]) |]
gen (Literal s:xs) x = gen xs [| $x ++ $(string s) |]

printf :: String -> Expr
printf s = gen (parse s) [| "" |]

-- using printf
printfTest = do 
	$(printf "A number %d and a string %s.\n") 69 "foo"
	$(printf "Just a number %d") 7
\end{lstlisting}

While Template Haskell has opened up many possibilities to the Haskell world, let us examine just one application of it: its role as a possible automated interface generator, thus fulfilling the same role as tools such as \ctohs, Green Card\footnote{\url{http://www.haskell.org/greencard/}}, or HaskellDirect\footnote{\url{http://www.haskell.org/hdirect/}}.  One can use Template Haskell as a sophisticated pre-processing system, but instead of generating text files that contain Haskell code---as most interface generators do---the Haskell code is generated directly, in the form of templates.  By calling template functions with the appropriate parameters, the resulting code produced by the templates can model the target API.  Since the compiler executes the template code at compile-time, not only can templtes perform the interface generation, but the interface generation is far more convenient since it is integrated into the compilation process.  There is no separate pre-processor step required.

Of course, this simple means of using Template Haskell as an interface generator still requires the programmer to tell the template functions which interface APIs to generate; e.g.\ a Template Haskell-based IDL compiler would still require an IDL specification in some form.  So far, the only difference that Template Haskell has made is saving a step in the build process of an application, by eliminating the need to execute a pre-processor before compilation.

\subsection{Autogeneration of Interface Definitions}

\begin{quote}
The three principle virtues of a programmer are Laziness, Impatience, and Hubris. \emph{--- Larry Wall, ``Programming Perl''}
\end{quote}

It would be very convenient if a template-based interface generator can automatically find the interfaces presented by the target API.  If this is possible, then the task of mapping a component system's API in Haskell can be completely automated.

In fact, automating the search for interface definitions in Template Haskell would be exactly the same as automating it if a standalone tool such as \ctohs was being used, because arbitrary IO can be performed in Template Haskell via the \emph{quotation IO monad}.  While templates are being spliced in by the compiler, files or network sockets can be opened and even external programs may be executed---all during compilation!

Ian Lynagh uses this technique to great effect when creating a Haskell interface to the UNIX \texttt{curses} library\cite{LYNA03}.  He first uses Template Haskell to splice in declarations of FFI \inline{foreign import} statements automatically into a module, which eliminates the need for the programmer to manually write those declarations.  However, Lynagh then proceeds to build the C wrapper functions required by the just-declared FFI imports as \inline{String}s, writes out those C wrapper functions to C source and header files using the quotation IO monad, and then calls \texttt{gcc} \emph{inside the splice} to compile the C wrapper functions which were just written!

So, by using Template Haskell and the quotation IO monad, Lynagh manages to completely automate building the \texttt{curses} binding.  With no preparation beforehand, a programmer who wishes to access the \texttt{curses} API simply has to put in one splice in his program, and the templates will generate the code to build the binding, and expose the \texttt{curses} API in Haskell to the programmer---in one line of code.  It would be easy to modify Lynagh's \texttt{curses} example to suit various other APIs: interface definitions could be generated from header files, XML  definitions of the API or \emph{JavaDoc} documentation.  This shows that while Template Haskell is certainly useful as a simple replacement for an interface generator, it wields far more power when it can be used to automatically find the interface information as well.

The convenience that this brings to the programmer should not be underestimated.  Arguably, a large reason why Haskell bindings to foreign APIs are not used more often is that programmers simply don't want to go to the trouble of building an API binding.  At the very minimum, the interface generator must be built.  Often, the programmer then has to find the interface definitions, and give the interface generator those definitions using a special syntax, so that the final API binding can be produced.  Template Haskell eliminates those steps: instead, the programmer simply has to write a few extra lines of code to splice in the templates, which do all the magic work behind-the-scenes during compilation.  Hopefully, programmers will take advantage of more API bindings if they are simpler to use.

\subsection{Reflecting on Interface Definitions}

Besides using the quotation IO monad to automatically search for and generate interface definitions, Template Haskell can also execute FFI functions in a splice, and let the FFI functions return the information necessary for the generation of interface definitions.  While this is not as flexible as performing arbitrary IO to derive interfaces, it is also sufficient (and preferred) when interfacing to component systems or object-oriented systems with reflection capabilities.  Template Haskell simply FFI-calls the component system's reflective functions to locate components in the system and derive their interfaces.  This has a number of advantages over using the quotation IO monad to generate the interfaces:

\begin{itemize}

	\item Since the component system's reflective functions are invoked directly, it is guaranteed that the interface definitions given to the generator are \emph{accurate}.
	
	\item It is \emph{safer} than performing IO: the programmer is assured that the Haskell template code cannot execute arbitrary programs, unlink files, or write politically incorrect messages all over the user's terminal.

\end{itemize}

Thus, a target API's reflective capabilities can be used to automatically derive the information necessary to generate the interfaces.  Again, all that may be necessary on the user's part is writing a few splices in their code, to direct the interface generator will do its work at compilation time using Template Haskell.

\section{Upcasting and Downcasting Objects in the Class Hierarchy}

\begin{quote}
No-one likes to be typecast, anyway. \emph{--- Larry Wall}
\end{quote}

All object-oriented systems have \emph{container objects}: these are objects which, as the name implies, can contain other objects.  Canonical examples of container objects include lists, dictionaries and finite maps; other not so immediately obvious examples include a GUI object-oriented toolkit, using container classes such as a GUI window which can contain many other types of GUI objects.

When the contained object is \emph{retrieved} from the container object, there are two possibilities: either the retrieved object will be of the exact same type that it was before it was inserted into the container, or it may be a \emph{supertype} of the original object\footnote{If a type $\alpha$ is a subtype of another type (i.e.\ it inherits from) $\beta$, then $\beta$ is a supertype of $\alpha$.}.  To obtain the original type of the object, one must \emph{cast} (or \emph{coerce}) the retrieved object to its original type.  Casting from a supertype to one of its subtypes is more specifically known as \emph{downcasting}; casting from a subtype to a supertype is called \emph{upcasting}.

Since upcasting and downcasting is a necessary operation in an object-oriented class hierarchy, it is essential to implement those operations to properly model an object-oriented class hierarchy in Haskell.

To provide an example class hierarchy, recall the Java code in \lstrefpage{listing:javaMultipleInheritance}, visualised in \figrefpage{fig:JavaClassHierarchyExample}.  Contrast the code with the Haskell equivalent in \lstrefpage{listing:typeClassesMultipleInheritance}, visualised in \figrefpage{fig:HaskellClassHierarchyExample}.  In this small class hierarchy, there are six possible casting operations which can be performed:

\begin{enumerate}

	\item an upcast from \inline{Sub} to \inline{Super},
	
	\item a downcast from \inline{Super} to \inline{Sub}\footnote{The downcast assumes that the object being casted is actually of the type \inline{Sub}.\label{footnote:downcasting}},
	
	\item an upcast from \inline{Sub} to \inline{AnInterface},
	
	\item a downcast from \inline{AnInterface} to \inline{Sub}\footref{footnote:downcasting},
	
	\item an upcast from \inline{Sub} to \inline{AnotherInterface},
	
	\item a downcast from \inline{AnotherInterface} to \inline{Sub}\footref{footnote:downcasting},

\end{enumerate}

Note that the names of the classes used here (such as \inline{Sub} and \inline{AnInterface}) correspond to the names of the classes given in the object-oriented Java class hierarchy.  The corresponding casts in the Haskell class hierarchy would be upcasting and downcasting between \inline{SubInstance}, \inline{SuperInstance}, \inline{AnInterfaceInstance}, and \inline{AnotherInterfaceInstance}.

The problem is how to provide such upcasting and downcasting in Haskell.  Haskell does not innately provide any such casting operations in the base language: there is no equivalent to C's \lstinline[language=C]{(int *)} operator in Haskell to, e.g.\ cast the result of a \inline{malloc} expression from a \lstinline[language=C]{void *} to an \lstinline[language=C]{int *}.  How, then, can upcasting and downcasting be performed in Haskell?

\subsection{Upcasting and downcasting with \inline{from\emph{x}} and \inline{to\emph{x}}}

One solution is to require any instances of the type class \inline{Super} to implement the two functions shown in \lstref{listing:updowncastSuper}: \inline{toSuperInstance} and \inline{fromSuperInstance}.

\begin{lstlisting}[float, caption={Up/downcasting functionality for the \inline{Super} object-oriented class}, label=listing:updowncastSuper]
class Super s where
	-- give the type system an assertion that a expression foo of type
	-- `s' can be `cast' to the SuperInstance type, by _fixing_ the
	-- type variable `s' with "foo :: SuperInstance"
	toSuperInstance :: s -> SuperInstance
	-- `cast' any instances of Super, from the instance type to an
	-- ambiguous type variable which belongs to the type class
	fromSuperInstance :: SuperInstance -> s

data SuperInstance = SuperInstance -- some opaque data type
data SubInstance = SubInstance

instance Super SuperInstance where
	-- toSuperInstance :: SuperInstance -> SuperInstance
	toSuperInstance x = x -- or also "toSuperInstance = id"
	-- fromSuperInstance :: SuperInstance -> SuperInstance
	fromSuperInstance x = x -- or also "fromSuperInstance = id"
	
instance Super SubInstance where
	-- toSuperInstance :: SubInstance -> SuperInstance
	toSuperInstance (SubInstance) = SuperInstance
	-- fromSuperInstance :: SuperInstance -> SubInstance
	fromSuperInstance (SuperInstance) = SubInstance
\end{lstlisting}

The function \inline{toSuperInstance} will upcast an expression of any type which belongs to the type class \inline{Super} to the \inline{SuperInstance} data type: \lstref{listing:fromToUsage} demonstrates how it can be used to perform upcasting.

The function \inline{fromSuperInstance} is slightly more complex; it will cast an expression of the \inline{SuperInstance} type to an \emph{ambiguous type variable} \inline{s}.  \lstref{listing:updowncastSuper}{} shows that the type signature of \inline{fromSuperInstance} is \lstinline{:: SuperInstance -> s}, which means that the final type of \inline{fromSuperInstance} must be explicitly specified, or \emph{fixed}, for the type system to determine exactly which implementation of \inline{fromSuperInstance} to call.  \lstref{listing:fromToUsage}{} shows how to use \inline{fromSuperInstance} to perform downcasting, and \figref{fig:HaskellClassHierarchyCasting} visualises how the downcast is performed.

\begin{lstlisting}[float, caption={Using \inline{fromSuperInstance} and \inline{toSuperInstance} to perform casting}, label=listing:fromToUsage]
-- an instance of super; we only care about the type for this example,
-- the value doesn't matter
super :: SuperInstance

-- downcasting from the `super' type to the `sub' type
sub = fromSuperInstance super :: SubInstance

-- upcasting from the `sub' type to the `super' type
super' = toSuperInstance sub
\end{lstlisting}

\begin{figure}[htbp]
\centering
\includegraphics[width=\textwidth]{HaskellClassHierarchyCasting}
\caption{Visualisation of downcasting from \inline{SuperInstance} to \inline{SubInstance}, in a Haskell class hierarchy}
\label{fig:HaskellClassHierarchyCasting}
\end{figure}

This use of \inline{from\emph{x}} and \inline{to\emph{x}} functions to perform type conversion is not a novel idea: the Haskell 98 standard uses this exact technique by defining the functions \inline{fromInteger} and \inline{fromInt} in the \inline{Num} type class.

The interface generator \ctohs\cite{C2HS} also uses this technique.  It provides a feature named \emph{class hooks}, which generates two functions per object-oriented class.  These two functions are isomorphic to the \inline{from\emph{x}} and \inline{to\emph{x}} functions described in this section.

\subsection{Convenient casting: \inline{upcast} and \inline{downcast}}

While the respective \inline{from\emph{x}} and \inline{to\emph{x}} functions can perform the casting, \lstrefpage{listing:fromToUsage} shows that they can be confusing to use because of the syntax difference between upcasting and downcasting.  While upcasting uses the reasoanbly straightforward syntax \inline{toSuperInstance sub}, downcasting is more cumbersome: \lstinline{fromSuperInstance super :: SubInstance}.  Moreover, the inconsistent syntax between upcasting and downcasting is rather unfriendly to a programmer's memory.

Casting should use a convenient, consistent syntax: \lstinline{downcast super :: SubInstance} for downcasting, and \lstinline{upcast sub :: SuperInstance} for upcasting.  It is possible to do this by using \emph{multi-parameter type classes}: a Haskell 98 extension which, as the name indicates, permits more than one parameter for a type class.  \lstref{listing:upDownCast} shows an implementation of \inline{upcast} and \inline{downcast} using multi-parameter type classes.

\begin{lstlisting}[float, caption={[The \inline{downcast} and \inline{upcast} functions]The \inline{downcast} and \inline{upcast} functions, implemented using multi-parameter type classes}, label=listing:upDownCast]
class Cast sub super where
	upcast :: sub -> super
	downcast :: super -> sub

data SuperInstance = SuperInstance -- some opaque data type
data SubInstance = SubInstance

instance Cast SubInstance SuperInstance where
	upcast SubInstance = SuperInstance
	downcast SuperInstance = SubInstance
\end{lstlisting}

One interesting point about using a dedicated \inline{Cast} type class to implement the \inline{upcast} and \inline{downcast} functions is that the casting function is completely independent of objects.  An object-oriented class hierarchy is not required to use these casting functions.

There is no reason why a more general \inline{cast} function, which performs either an upcast or downcast, cannot be implemented.  Indeed, this more closely mirrors the usage of the cast operation in C, C++ and Java.  However, the definition of a \inline{Cast} type class which requires both \inline{upcast} and \inline{downcast} functions ensures that it is impossible to implement an \inline{upcast} function without implementing its corresponding \inline{downcast} function.

\subsection{Statically type-checking casting}

By listing valid casts as instances of the \inline{Cast} type class, the type checker is made aware of all possible casting operations, so  all casts are statically type-checked to see if they are valid.  One cannot upcast from \inline{Foo} to \inline{Bar} if there has been no declaration that \inline{Foo Bar} is an instance of the \inline{Cast}.

\subsection{Dynamically type-checking casting}

Many component systems allow for dynamically typed objects, which implies that there may be objects used whose types are not known at compile-time.  It is even possible for the component system to demand-load components at runtime, send messages to those components, and receive a message reply which is a ambiguous object whose true type is unknown.  However, according to knowledge gained at compile time about the system, this ambiguous object's type \emph{should} be a subtype of \inline{AnInterface}.  Casting these objects to an interface\footnote{`Interface', as used here, is equivalent to the Java definition of the term: i.e.\ a class which only specifies type signatures for its methods, and possesses no function implementations.} subtype is common practice in many component systems.

Component systems and object-oriented programming languages therefore support and use \emph{dynamic casts} extensively.  As such, convenient support for dynamic casts must be made available in Haskell.  While implementing dynamic casts varies from one component system to another, it is possible to provide a universal approach for their implementation.

A dynamic cast is simply a type check performed at runtime by the component system.  Therefore, to implement dynamic casts, the \inline{upcast} and \inline{downcast} functions call a function provided by the component system (via the FFI), which verifies that the cast can be performed.  An appropriate action---such as throwing a Haskell exception---can be taken if the cast fails; otherwise, the dynamic cast proceeds normally.

\section{Class Objects}

In some object-oriented languages, defining a new class results in not only a new type, but also a new \emph{class object}.  Class objects are concrete representations of that class, and are typically used as \emph{factory objects} which produce new instances of the class on request.  Many object-oriented languages which use reflection have class objects, e.g. Smalltalk, Objective-C and Java\footnote{Java hides the use of the class object as a factory, by having an explicit \inline{new} operator.  In contrast, Objective-C requires that the programmer directly invoke a method on the class object to produce an instance object}.  To properly model these object-oriented systems' class hierarchies, Haskell must support the use of class objects.

Representing a class object in Haskell can be performed via a function which returns the class object, by calling the appropriate methods in the target object-oriented language.  In addition, the Haskell class hierarchy model should be extended to support two different inheritance trees: one inheritance tree for class instances, and another inheritance tree for class objects.  Since there are now two trees, it is also advisable to provide two new data types which act as the \emph{root} of the instance and class object trees.  \lstref{listing:classObjectsHierarchy} shows how such a mapping can be achieved; for a visual perspective on the class hierarchy, see \figref{fig:classObjectsHierarchy}.

\begin{lstlisting}[float, caption=Modelling a class hierarchy which includes class objects, label=listing:classObjectsHierarchy]
class Object o
data UniversalObject -- can represent any object
instance Object UniversalObject

-- the inheritance tree for instances
class Object i => Instance i
data InstanceObject -- can represent any instance object
instance Object InstanceObject
instance Instance InstanceObject

class Instance s => Super s
data SuperInstance -- some opaque type
instance Object Super
instance Instance SuperInstance
instance Super SuperInstance

class Instance s => Sub s
data SubInstance
instance Object SubInstance
instance Instance SubInstance
instance Super SubInstance
instance Sub SubInstance

-- the inheritance tree for class objects
class Object c => Class c where
	-- Given the name of a class, returns its class object
	getClassObjectFromName :: String -> c
	-- Given a class object, returns its name
	classObjectName :: c -> String
      
data ClassObject -- can represent any class object
instance Object ClassObject
instance Class ClassObject

class Class s => SuperClass s
data SuperClassObject
instance Object SuperClassObject
instance Class SuperClassObject
instance SuperClass SuperClassObject

class Class s => SubClass s
data SubClassObject
instance Object SubClassObject
instance Class SubClassObject
instance SuperClass SubClassObject
instance SubClass SubClassObject
\end{lstlisting}

\begin{figure}[tbp]
\centering
\includegraphics[width=\textwidth]{HaskellClassHierarchyWithClassObjects}
\caption{Visualisation of a Haskell class hierarchy which includes class objects.  Ellipses with solid outlines represent data types, and ellipses with dashed outlines represent type classes.}
\label{fig:classObjectsHierarchy}
\end{figure}

\subsubsection*{A more elegant way to retrieve class objects}

Even though this class hierarchy model enables retrieving class objects, it is still slightly cumbersome to use \inline{getClassObjectFromName} for this task; writing \lstinline{getClassObjectFromName "Sub"} will not work since the final type of that expression is still a type variable which may be any class object.

It would be preferable to have a dedicated \inline{getClassObject} function which only needs to be given a type signature to determine which class object to retrieve, e.g.\ \lstinline{getClassObject :: SubClassObject}.  \lstref{listing:getClassObject} shows how using a recursive \lstinline{let} definition can be used to write such a \inline{getClassObject} function.  Since the definition is of \inline{getClassObject} is not straightforward to understand, Appendix \ref{appendix:getClassObject} (page \pageref{appendix:getClassObject}) provides an explanation of how the function works.

\begin{lstlisting}[float, caption=The \inline{getClassObject} function, label=listing:getClassObject]
getClassObject :: Class c => c
getClassObject =
	let
		x = upcast (getClassObjectFromName (classObjectName x))
	in
		x
		
-- usage:
_Sub_ = getClassObject :: SubClassObject

_Super_ = getClassObject :: SuperClassObject
\end{lstlisting}

\lstref{listing:getClassObject} also provides two functions which represent class objects: \inline{\_Sub\_} and \inline{\_Super\_}.  The rest of this thesis will assume that a function with a \inline{\_\emph{classname}\_} naming scheme represents a class object.

\subsubsection*{Metaclass objects}

Some object-oriented languages also have \emph{meta-class objects} (and possibly even \emph{meta-meta-class objects}), which serve as the class objects of the class objects.  It is straightforward (if not a little bit tedious) to provide three or more inheritance trees to represent such (meta-)meta-class objects, and to implement a similar \inline{getMetaclassObject} function if one is needed.  The \inline{\_\emph{classname}\_} syntax used to retrieve a class object can be logically extended to \inline{\_\_\emph{classname}\_\_} for metaclass objects.

\section{Representing Components and Objects in Haskell}
\label{section:representingComponents}

Now that an approach to model and automatically generate an object-oriented class hierarchy in Haskell is available, an obvious problem is how to \emph{represent} an object or component in Haskell.  What Haskell data type should be given to foreign components?

The question of how to represent objects in Haskell can be made more specific: what is the most \emph{convenient} way to represent the object in Haskell?  One can have two non-exclusive points of view about the convenience of an object representation: is it convenient for an \emph{author} who is writing a binding from Haskell to the component system to manipulate objects, and is it convenient for a \emph{user} of such a binding to manipulate objects?  These two goals should be kept in mind, so that both writing a binding and using the binding is as straightforward as possible.

One obvious solution to this problem is simply duplicating each of the desired component's properties in a Haskell data type.  Every object has methods and perhaps some public instance variables.  If the Haskell environment can directly access these properties, perhaps by writing to the object's address space (for example, by making the object an instance of the FFI \inline{Storable} type class), then component communication simply consists of direct function calls to invoke methods, reading and writing an object's instance variables can be performed with \inline{peek} and \inline{poke}.

This approach of duplicating as much of the target component as possible inside the Haskell environment has two drawbacks:

\begin{enumerate}

	\item The target component system is not likely to expose the object's internals so easily, since encapsulation is an extremely important goal of component systems.  A CORBA or DCOM component may reside on an Internet e-Business Enterprise Application Server running on a different operating system or architecture, which makes it impossible to directly replicate the component's address space layout in the Haskell environment.  
	
	\item Representing as much of a component as possible increases---not decreases---the cost of \emph{marshalling} the component to and from the component system.  Any direct representation of an object's data in Haskell requires code in the Haskell environment to perform operations on the data.
	
\end{enumerate}

Given these drawbacks, a logical alternative solution is to use the most \emph{abstract} representation of an object or component, and this solution will indeed suffice for the majority of component systems.  For instance, the most abstract representation of an object in Objective-C is simply a C pointer, which is easy to represent and marshal in Haskell.  Similarly, Java uses an \emph{object reference} to represent an object, which is the Java Virtual Machine's equivalent to a C pointer.

By using a highly abstract representation of a foreign component, a Haskell binding can use of all the component system's native capabilities to operate on the component, instead of re-writing all those operations in the component binding.  After all, the component system must know how to access its own components, no matter how abstract its representation is!  This approach is also less dependent on the component's representation, which allows the target component system to change and evolve without affecting bindings to the system.

\subsubsection*{Pointers to components}

Since many object-oriented languages use a pointer as their most abstract representation of an object, how can one represent a pointer in the Haskell environment?  The FFI provides a  \inline{Ptr} type for exactly this purpose, so it seems that this problem is easily solved.  While it is easy to use type synonyms such \lstinline{type Super = Ptr ()} and \lstinline{type Sub = Ptr ()} to use void pointers to represent objects, there are two significant problems with this approach:

\begin{enumerate}

	\item Pointers are typed.  Both C and Haskell's type systems distinguish between an \inlinec{int *} (\inline{Ptr Int}) and a \inlinec{void *} (\inline{Ptr ()}), for example.  Using type synonyms does not enable the type checker to distinguish between different types of objects.  The \inline{Super} and \inline{Sub} types given in above example would be treated as exactly the same type.
	
	\item Since type synonyms are nothing more than aliases, each type synonym cannot be made instances of different type classes.  This renders it impossible to use the type class \& data type scheme described by Shields and Peyton Jones\cite{SHIE01} to model the object-oriented class hierarchy.
	
\end{enumerate}

These two problems indicate that either the Haskell \inline{data} or \inline{newtype}  declarations must be used to declare \inline{Ptr}s.  Here, the less popular \inline{newtype} declaration is the better option.  To see why, the Haskell 98 report explains what \inline{newtype} is intended for:

\begin{quotation}
A declaration of the form \inline{newtype} introduces a new type whose representation is the same as an existing type. The [new] type renames the datatype \ldots It differs from a type synonym in that it creates a distinct type that must be explicitly coerced to or from the original type. Also, unlike type synonyms, \inline{newtype} may be used to define recursive types \ldots These coercions may be implemented without execution time overhead; \inline{newtype} does not change the underlying representation of an object.

New instances \ldots can be defined for a type defined by \inline{newtype} but may not be defined for a type synonym. \emph{--- Haskell 98 report\cite{PEYT03}, Section 4.2.3.}
\end{quotation}

An important property of \inline{newtype}s not quoted from the report is that any \inline{newtype}s created are automatically marshallable by the FFI, if the type that they rename is also marshallable by the FFI.

Another useful technique is to make the \inline{newtype} declaration recursive, e.g.\ \inline{newtype Object = Object (Ptr Object)}.  This allows any methods which \emph{unpack} the data type to still observe that the pointer in the data type does is indeed typed, and points to an \inline{Object}.  Lazy evaluation ensures that the parameterised type argument in \inline{Ptr} will never be evaluated.  \ctohs{} uses this technique when automatically generating pointer declarations with its \emph{pointer hooks}.


%%%%%%%%%%%%%%%%%%%%%%
\chapter{Component Communication}
%%%%%%%%%%%%%%%%%%%%%%
\label{chapter:componentCommunication}

Given a design for modelling an object-oriented class hierarchy in Haskell, we now address the question of how to communicate with other components.  While the way to model an object-oriented class hierarchy is powerful, is it possible to communicate with other objects/components without sacrificing any of the power of this model?  It is possible to build well-typed messages which contain these objects, send those messages to and from other objects, and receive object types as a message reply?  Is it possible to do this while still retaining features such as Haskell's type inference?

\section{Sending Messages: the Low-Level Interface}

The first problem to overcome is how to actually send messages to and receive messages from other components.  This problem is tackled first, because it may have a significant impact in how the rest of the communications library is designed.  For example, if the low-level messaging functions are allowed to send and receive messages which contain values of any type, then this may ease the design of the rest of the communications library, compared to the situation where the types are restricted.

\subsection{The Foreign Function Interface}

Other Haskell language bindings have all used the standardised Foreign Function Interface (FFI) to call functions written in other languages, and for good reason.  The FFI is the \emph{d\'e facto} way for Haskell environments to interact with external environments such as the operating system or other programming languages.  The FFI is most often used to call C functions, since the majority of operating system APIs are written in C.  However, it is not limited to C: the FFI is designed in such a way to perform function calls for any language or platform, and in its present form already incorporates support for calling functions written for the C, C++, .NET, Java Virtual Machine, and  Win32 platforms.

\subsection{The FFI: Extend or Embrace?}

Since the FFI is extensible, there are two possibilities for how to use it to communicate with component systems:

\begin{enumerate}

	\item extend the FFI to natively support the desired component system, enabling direct method invocation on components, or
	
	\item implement \emph{proxy} or \emph{stub} functions in a language which the FFI already supports, and rely on the proxy functions to establish communication channels with the component system.

\end{enumerate}

It is tempting to extend the FFI to natively support communicating with the desired component system, but there one major practical drawback to this approach: it's a lot of work.  An FFI extension would have to be implemented for each different Haskell compiler or interpreter.  To emphasise this point, many Haskell environments only support the C and Win32 calling conventions.  Some component systems, such as CORBA, do not even define a standard calling convention, so extending the FFI to natively support the communications protocols of those component systems doesn't make any sense---there is no standard communications protocol to support!  To extend the FFI to communicate with these sorts of systems, we would have to instead target one or more particular implementations of the component system's reflection service.  For example, instead of bridging to CORBA, the FFI could be extended to enable communication via CORBA's IIOP messaging standard, or perhaps via a concrete Object Request Broker implementation such as ORBit.

So, while having a native method of communication with the component system would be quaint, we will instead choose to take advantage of the popular support for the C and Win32 FFI bindings.  As long as the goal of communicating with the component system is achieved, this design decision will enable a component interface to work across multiple Haskell implementations, and is arguably a less complicated and less error-prone path to walk.

It can be said that this choice simply shifts the problem of marshalling messages from Haskell to whatever proxy language is chosen in for the component binding (such as C).  However, the point of this problem-shift is that it is far more likely that bindings already exist for talking to the component system in the external language.  There are numerous implementations of the IIOP messaging protocol in C, for example.

Note that by using the FFI to communicate with external components, the implementation of the communications library will be bound by the FFI's capabilities.  For example, the FFI restricts the type definitions of the foreign functions: it allows only a small set of \emph{basic foreign types} to be passed between external functions and Haskell.  Moreover, if a specific FFI language binding such as C is chosen, the types which can be used will be further restricted by the C-specific part of the FFI.

In reality, this restriction is not too worrisome since it is possible to interchange arbitrary data types back and forth from Haskell, as long as those data types are instances of the \inline{Storable} type class.  (Keep in mind that the FFI permits the construction of \inline{Storable} instances for any data type, and this is exactly what interface generation tools such as \ctohs---or Template Haskell---can be used for.)  Still, this means that we must be conscious about the FFI's restrictions during the design of the communications interface.

\subsection{C as the Proxy Language}

To keep examples simple, we will assume that C is being used as a proxy language for the rest of this thesis.  The Haskell environment will call C functions to send messages, and it is the responsibility of the C functions to communicate with the component systems.  How the C implementation works is irrelevant: it is sufficient as long as it can \emph{forward} the messages from Haskell to the component system, and return any message replies from the component system back to Haskell.

C has been chosen not only because it is the most common FFI language binding available, but also because it is quite restrictive.  Other proxy languages or platforms such as .NET or the Java Virtual Machine can of course be used, but they may have extra features (such as innate ad-hoc polymorphism capabilities) which C does not possess.  It is ideal to design a communications interface which will be usable on as wide a range of FFI language bindings as possible.

\subsection{Messages, Receivers \& Message Expressions}

In Java, a method invocation on a component is performed by writing \inlinej{aComponent.aMethod(argument1, argument2, ...)}.  Using this example, let us define a few terms more specifically:

\begin{description}

	\item[Message] The name of the method to invoke, along with any of its arguments; e.g.\ \inlinej{aMethod(argument1, argument2, ...)}.
	
	\item[Receiver] The object/component which receives the message, e.g.\ \inlinej{aComponent}.
	
	\item[Message Expression] A particular instance of a message together with a corresponding receiver, i.e.\ a concrete representation of a method invocation.
	
\end{description}

Thus, to send a \emph{message}, one needs to pair it with a \emph{receiver}, which produces a resulting \emph{message expression}.

It is possible to represent these elements of a method invocation in Haskell by defining them as data types.  For example, one possible way to define these types is shown in \lstref{listing:mrmeDefinition}.

\begin{lstlisting}[float, caption={Definitions of the \inline{Message}, \inline{Receiver}, and \inline{MessageExpression} data types}, label=listing:mrmeDefinition]
data Message a = Message a
-- a is the message's arguments, given as tuples such as (foo, bar).
-- Note that we can't use a list to represent the arguments, since
-- each argument may be a different type.

type Receiver = UniversalObject

data MessageExpression a = MessageExpression (Message a) Receiver
\end{lstlisting}

However, there is a problem if method invocations are defined using such data types: eventually, we must call the C proxy message functions to send messages, which means that the \inline{Message} type must be a type which can be marshalled by the FFI.  So, the \inline{Message} type must either be basic foreign type or an instance of the \inline{Storable} FFI type class, which implies that implementations of the functions required by \inline{Storable} (such as \inline{peek} and \inline{poke}) must be written.

In order to make marshalling easier, a Haskell data type which is already an instance of \inline{Storable} can be used: the humble pointer (\inline{Ptr}) type.  Instead of defining the data types for \inline{Message}, \inline{Receiver} and \inline{MessageExpression} similarly to \lstrefpage{listing:mrmeDefinition}, it is sufficient to define them as \inline{Ptr}s and simply use extra C functions to set the primitive information about a message expression's contents, as shown by \lstref{listing:MessageExpression}.

\begin{lstlisting}[float, caption=Primitive \inline{MessageExpression} functions, label=listing:MessageExpression]
newtype MessageExpression =
	MessageExpression (Ptr MessageExpression)

type Receiver = UniversalObject

foreign import ccall
	makeMessageExpression :: IO MessageExpression
	
foreign import ccall
	setReceiver :: MessageExpression -> Receiver -> IO ()
	
foreign import ccall
	setMethodName :: MessageExpression -> CString -> IO ()
	-- assuming that the method name to invoke is a C string	
foreign import ccall
	setCIntArgument :: MessageExpression -> Int -> CInt -> IO ()
	-- the `Int' argument specifies which index in the argument list
	-- to set
foreign import ccall
	setCStringArgument :: MessageExpression -> Int -> CString -> IO ()
	-- (repeat for the rest of the C basic foreign types) ...
\end{lstlisting}

There are a few noteworthy points about representing message expressions in this manner:

\begin{itemize}

	\item Defining a data type using the \inline{newtype} keyword instead of \inline{data} will automatically make the newly defined type marshallable, as long as the type referred to in the \inline{newtype} declaration (in this case, a \inline{Ptr}) is also marshallable.
	
	\item Only a \inline{MessageExpression} data type needs to be defined.	
	\item There is no need to marshal an argument list (at least, not in the low-level communications layer), which may be of varying length and can contain elements of different types.  Instead, extra C functions are available to individually set each argument in a message expression.
	
	A disadvantage of this design is that there must be one function for every possible type of an argument, but this not a problem since there are only a limited number of basic foreign C types.  This design is also completely type-safe, in both the Haskell and C environments.
	
	\item The representation of the message expression has been moved from the Haskell environment to the C environment.  Exactly how the message expression is represented in the C environment is completely inconsequential to the Haskell/C interface.
	
	This has another extra benefit: if the component system has already defined a data type for a method invocation or message expression, the C proxy functions can simply use that data type to represent the message expression, instead of having to define one.  This may make communication with the component system a bit more speedy, since the C functions (and thus the Haskell code) may be using the component system's native representation of a method invocation.  Of course, one could argue that this speed benefit would also apply if the native data type was represented in Haskell, but again, the component system is likely to have C bindings already available, which saves writing more code.

\end{itemize}

After defining the C proxy functions, it is now possible to build message expressions in Haskell.  Still, message expressions are relatively useless if they are never used, so let us now address how to send the message expressions to the component system.

\subsection{The mailman arrives}

The one thing which is required to send a message expression is simply a definition of the C function to send it, as shown in \lstref{listing:sendMessageExpressionWithNoReply}.

\begin{lstlisting}[float, caption=\inline{sendMessageExpressionWithNoReply} interface, label=listing:sendMessageExpressionWithNoReply]
foreign import ccall
	sendMessageExpressionWithNoReply :: MessageExpression -> IO ()
\end{lstlisting}

This leaves the responsibility of the actual message sending completely in the hands of the C function.  How the message sending is performed varies between component systems, and is thus not a concern for the Haskell/C interface.

Of course, this assumes that the message expression does not receive a reply of some sort.  Since it is rather desirable to receive replies from the component system, \lstref{listing:sendMessageExpressionWithXReply} defines a few more C functions which can extract the reply from a sent message expression, and pass it back to Haskell.

\begin{lstlisting}[float, caption=Other \inline{sendMessageExpressionWith\emph{x}reply} functions, label=listing:sendMessageExpressionWithXReply]
foreign import ccall
	sendMessageExpressionWithIntReply :: MessageExpression -> IO Int
foreign import ccall
	sendMessageExpressionWithIntReplyP :: MessageExpression -> Int
	-- `Pure' version of the above (has no side effects); useful for,
	-- e.g. using a math library component.  Define a pure version
	-- for each type of reply if appropriate.

foreign import ccall
	sendMessageExpressionWithCStringReply ::
		MessageExpression -> IO CString

foreign import ccall
	sendMessageExpressionWithUniversalObjectReply ::
		MessageExpression -> IO UniversalObject

-- etc ...
\end{lstlisting}

Again, the C functions are responsible for extracting the reply and passing them back to Haskell, and how this is performed depends on the component system.

Note that using these low-level functions to receive replies from messages \emph{may break type safety}: if \inline{sendMessageExpressionWithIntReply} is called and the C function passes back a \inline{CString} as a result, then behaviour from that point is undefined.  If the component system's message passing protocol has the functionality to obtain the type of the message reply, it is certainly possible to add in type checks which will be performed at run-time and return a exception if such a type mismatch occurs.  This is a prudent idea, and it is up to the C proxy functions to perform these dynamic type checks and propagate any type errors back to the Haskell environment.  Type checking can also be enforced if it is known at compile-time that sending a particular message will always evoke a reply of a certain type.  However, it is not the responsibility of the low-level communications interface to perform this static type checking: since a component system may be inherently dynamically typed, the message sending functions must  also be dynamically typed.

Now that it is possible to build message expressions and send them to a receiving component, we have a complete low-level interface in Haskell to communicate with a component system.  It is important to note that the concept of a message expression and the corresponding C functions to act on it are generalised enough to work with \emph{any} component or object-oriented system, and that an existing C binding for the component system can be used, if one is available, to implement most, if not all, of these functions---which saves much time and effort.

\section{Creating a friendlier mailperson}

While the low-level communication interface is necessary, it is evident that using these functions is not particularly convenient.  Not only is it necessary to set the arguments of a message expression individually, but different functions must be invoked depending on what types the arguments are.  Thus, the next priority is to \emph{wrap} the low-level functions with a higher-level interface, so a programmer can write code that builds \& sends message expressions in one line, instead of forty-two.

A convenient interface would be to have a generic \inline{sendMessage} function, which can be used to send a message that contains an arbitrary number of arguments to any receiver, as shown in \lstref{listing:idealSendMessage}.

\begin{lstlisting}[float, caption=An ideal interface for \inline{sendMessage}, label=listing:idealSendMessage]
	sendMessage aReceiver "aMethodName" arg1 arg2 arg3 -- :: IO ()
	sendMessage anotherReceiver "anotherMethod" arg1-- IO ()
	-- sendMessage may also return a value:
	aNumber <- sendMessage yetAnotherReceiver
		"yetAnotherMethod" arg1 arg2 -- IO Int
\end{lstlisting}

\subsection{Setting the Message Arguments}

Perhaps the most cumbersome aspect of the low-level interface are the functions which set the arguments of a message: \inline{setIntArgument}, \inline{setCStringArgument}, etc.  These functions are used in the same manner, except that the programmer must call a different version of the function depending on the type of the argument that they wish to set.  This is a perfect example of ad-hoc polymorphism, and Haskell offers type classes to solve this exact problem, as shown in \lstref{listing:setArgument}.

\begin{lstlisting}[float, caption=Using ad-hoc polymorphism to write \inline{setArgument}, label=listing:setArgument]
class Storable a => Argument a where
	setArgument :: MessageExpression -> Int -> a -> IO ()
	
instance Argument CInt where setArgument = setCIntArgument
instance Argument CString where setArgument = setCStringArgument
instance Argument UniversalObject where
	setArgument = setUniversalObjectArgument
-- etc ...
\end{lstlisting}

Now, to send a message with the arguments \lstinline{(6, 'n')}, instead of writing \lstinline{setCIntArgument 1 6; setCharArgument 2 'n'}, we instead write \lstinline{setArgument 1 6; setArgument 2 'n'}.  The burden of selecting the appropriate function is shifted from the programmer to the type system.

This approach of overloading the functions which marshals individual arguments is very similar in concept to the approach taken by Lambada\cite{FINN00}, although the equivalent type class used in Lambada (named \inline{GoesToJava}) can marshal more than one argument.  Our \inline{Argument} class works with just one argument.  

\subsection{Sending Variable Arguments in a Message}

In the ideal version of \inline{sendMessage} in \lstrefpage{listing:idealSendMessage}, it is possible to set the message arguments by simply passing them to \inline{sendMessage} as function parameters.  Unfortunately, it is impossible to define such a version of \inline{sendMessage}, since the number of message arguments can vary from message to message, and Haskell 98 does not permit definitions of functions with a variable number of function parameters.  This is for good reason: if a variable number of function parameters were permitted, two powerful Haskell features---partial application and currying---would be far harder (if not impossible) to implement.  How, therefore, do we implement a generic \inline{sendMessage} function which has a \emph{fixed} number of parameters, yet still allows for \inline{sendMessage} to work with variable numbers of arguments per message?

One solution is to allow for one of the parameters in \inline{sendMessage} to contain an arbitrary number of expressions.  We require this \emph{message arguments parameter} to have two properties:

\begin{enumerate}

	\item It must be able to store an arbitrary (but finite) number of message arguments.
	
	\item Each message argument may be of a different type, so the parameter which stores the message arguments must be able to accommodate different types of elements.
	
\end{enumerate}

\subsubsection*{Lists with existential types}

It is possible to use a normal Haskell list to represent the message arguments: lists are designed to contain an arbitrary number of elements, after all!  The problem is that lists can only hold elements of the same type: e.g.\ the list \lstinline{[6, 'n']} is ill-typed.
	
However, a Haskell 98 type extension known as \emph{existentially quantified data constructors with type classes} enables the construction of an \emph{existential type}.  An existential type can hold any arbitrary data type, which may optionally be contained by a type class.  \lstref{listing:existentialTypes} shows how they can be used to implement a list which stores different types of message arguments.
	
\begin{lstlisting}[float, caption=Using existential types for an argument list, label=listing:existentialTypes]
data OneArgument = forall a. Argument a => AnArgument a

-- how to use the data type as an argument list
arguments :: [OneArgument]
arguments = [AnArgument 6, AnArgument 'n']
\end{lstlisting}

While this technique enables the use of lists to encapsulate message arguments, it has two disadvantages:
	
\begin{enumerate}
	
	\item It is not standard Haskell 98.  While many Haskell environments support existential data types (including the Glasgow Haskell Compiler, HUGS, and the Chalmers Haskell Compiler/hbc), it is preferable to use standard Haskell 98 constructs where possible.
		
	\item It requires prefixing the data type constructor to every argument in the list, which is hardly convenient.  As demonstrated by \lstref{listing:sendMessageWithExistentialTypes}, even if the data constructor in \lstrefpage{listing:existentialTypes} was shortened from \inline{AnArgument} to simply \inline{A}, using the \inline{sendMessage} function would continue to be neither convenient nor elegant.
	
	\begin{lstlisting}[float, gobble=4, caption=Using \lstinline{sendMessage} with a list of existential types, label=listing:sendMessageWithExistentialTypes]
	sendMessage aReceiver "aMethod" [A 6, A 'n']
	\end{lstlisting}
		
\end{enumerate}

The inconvenience of the need to tag each argument with a data constructor is indeed a shame; otherwise, existential types would be a perfect way of marshalling arguments.

% \fixme up to here

\subsubsection*{A \inline{sendMessage} template}

Another solution to enable calling \inline{sendMessage} with multiple messages arguments simply bypasses the need to have a single parameter which contains the message arguments.  With Template Haskell, one can create a template for the \inline{sendMessage} function call, which, at compile-time, is evaluated to produce functions that have the correct number of message arguments for each particular message.  As an example of how this works, the original Template Haskell paper\cite{SHEA02} implements the C \inline{printf} function---which uses a variable number of arguments---in Haskell; the usage of \inline{printf} and an analogous \inline{sendMessage} function is shown in \lstref{listing:printFExample}.

\begin{lstlisting}[float, caption=Using Template Haskell versions of \inline{printf} and \inline{sendMessage}, label=listing:printFExample]
-- the $(...) syntax `splices' in a definition of a template,
-- which produces a specific instance of the function as appropriate

main = do
	$(printf "A string %s, a character %c and a number %d\n")
		"Foo" 'c' 69
	$(printf "Only the number %d\n") 69
	-- a possible analogous version of sendMessage
	$(sendMessage aReceiver aMethod) "Foo" 'c' 69 -- 3 arguments
	$(sendMessage anotherReceiver anotherMethod) 69 -- 1 argument
\end{lstlisting}

The trick to implementing \inline{printf} is that the template function for \inline{printf} is called with a format string, which explicitly tells \inline{printf} how many arguments follow the splice: in the first use of \inline{printf} in \lstrefpage{listing:printFExample}, the format string contains three \emph{conversion specifiers}: \inline{\%s}, \inline{\%c} and \inline{\%d}, so \inline{printf} knows that there are three arguments following the splice.  

This has implications for a how to implement a template version of \inline{sendMessage}: the \inline{sendMessage} template must know exactly how many arguments the message requires.  There are two approaches that can be taken to give \inline{sendMessage} this knowledge:

\begin{enumerate}

	\item \inline{sendMessage} determines the number of messages directly from the method name or the combination of the receiving object and method name: this is possible in some component systems.  Objective-C, for example, has method names such as \inline{initWithScheme:host:path:}; the number of arguments that each method requires is determined exactly by the number of colons (\inline{:}) in the method name.  Still, this may not be true of every component system, so this approach is not universal.
	
	Note that building a lookup table which yields the number of arguments required, given a method name, does not solve the problem, since it would not be possible to send message expressions for method names which are unknown at compile-time; this is a legitimate and often mandatory requirement if the component system is dynamic.
	
	\item Each \inline{sendMessage} function call would have to be explicitly annotated with the number of arguments that the method requires; e.g. \lstinline{$(sendMessage aReceiver aMethod 3) "Foo" 'c' 69}.  While this solution works, it is clearly an inconvenience for the Haskell programmer, and is also inelegant---it is preferable for \inline{sendMessage} to automatically infer the number of arguments needed for the message.

\end{enumerate}

So, while it is possible to use Template Haskell to enabling building a \inline{sendMessage} command that accepts a truly variable numbers of arguments, it will either not work for all component systems, or the programmer must explicitly specify how many arguments are used.  Another solution will have to be found.

\subsubsection*{Using tuples for message arguments}

The humble tuple is normally used to group together related items, such as the common \lstinline{(Key, Value)} tuple used for lookup tables.  Recall that the `message arguments' parameter passed to \inline{sendMessage} must have two properties: it must support encapsulating an arbitrary number of elements, and it must support message arguments of different types. Tuples have both these properties: they can be of any length (although usually the Haskell compiler imposes a limit on the maximum number of elements, such as 64), and they may contain elements of different types.

The problem is writing a \emph{function} which allows an arbitrary-length tuple: what would be its type signature?   A type signature of \lstinline{:: (a, b, c)} is perfectly acceptable; this allows a three-element tuple where each element may be of a different type.  However, it is impossible to give a type signature to a function which requires a tuple parameter of different lengths.

The trick is to not use tuples in the type signature at all.  Tuples are still used to `wrap' all the message arguments in a single parameter; they just don't appear in the type signature.  Instead, a type variable is used to represent the parameter where the tuple would normally be; the type variable can then accept \emph{any} type of parameter, including tuples of varying length.   \lstref{listing:sendMessageSignatureWithTypeVariable}{} shows how such a type variable may be used.

\begin{lstlisting}[float, caption=\inline{sendMessage} type signature with an arbitrary parameter, label=listing:sendMessageSignatureWithTypeVariable]
sendMessage :: Receiver -> MethodName -> a -> -- etc ...
\end{lstlisting}

There is one show-stopper problem with this, though: since the `message arguments' parameter given to \inline{sendMessage} can be of any type, one cannot do anything useful with that type---other than pass the parameter on to another function---since it is impossible to know what operations can be performed on it.  In particular, it is not possible to pattern match against the tuple to extract the elements from it, since it is not even known whether the argument passed to the function is, in fact, a tuple at all!

The goal, then, is to allow \inline{sendMessage} to accept a parameter with any particular type, except that the parameter passed to it needs to have certain properties: in this case, it should have the property of being a tuple, so that its elements can be extracted, and \inline{setArgument} can be called on each of them.  This requirement of a type possessing certain properties is exactly what type variable constraints and type classes are designed for; we therefore define an \inline{Arguments} type class\footnote{Note the \inline{s} on the end of \inline{Arguments}; this is a different type class to \inline{Argument} which was defined in \lstrefpage{listing:setArgument}.} in \lstref{listing:Arguments} which contains functions that allows for the extraction of the tuple's elements.

\begin{lstlisting}[float, caption=The \inline{Arguments} type class, label=listing:Arguments]
class Arguments args where
	arguments :: args -> Int
	elem1 :: Argument a => args -> a -- extract first element
	elem1 t = error "Attempted to extract 1st element from length "
		++ show (arguments args) ++ " tuple" -- default method
	elem2 :: Argument a => args -> a -- extract second element
	elem1 t = error "Attempted to extract 2nd element from length "
		++ show (arguments args) ++ " tuple"
	...
	elem63 :: Argument a => args -> a -- as many as is needed

instance Arguments () where
	arguments _ = 0
instance Arguments (a) where
	arguments _ = 1
	elem1 a = a -- or `elem1 = id'
instance Arguments (a, b) where
	arguments _ = 2
	elem1 (a, b) = a
	elem2 (a, b) = b
-- repeat for >= 2 arguments
\end{lstlisting}

This method of using a type class to represent and extract information from a tuple was inspired by, and is nearly the approach which Lambada\cite{FINN00} uses in its \inline{GoesToJava} type class, to marshal multiple arguments for a Java method invocation.  However, Lambada's \inline{GoesToJava} type class abstracts away the need to extract each message argument from the tuple: instead, it defines a function \inline{marshal} which extracts the elements from the tuple and calls the equivalent of \inline{setArgument} itself.

This approach used by Lambada is superior, not only because it allows the type class to be written with less code, but it also abstracts away the data type entirely: as long as the data type implements the \inline{marshal} function, it does not matter what data type is used to store the message arguments.  Thus, the \inline{Arguments} type class can be re-implemented more succinctly as shown in \lstref{listing:argumentsRedux}; our equivalent to Lambada's \inline{marshal} function is named \inline{setArguments}.

% silly literate parameter
\begin{lstlisting}[float, caption={The \inline{Arguments} type class, redux}, label=listing:argumentsRedux, literate={->}{$\to$ }{2}{=>}{$\Rightarrow$ }{2}{<-}{$\leftarrow$ }{2}{\\}{$\lambda$}{1}{>=}{$\geq$ }{1}{...}{\ldots }{3}]
class Arguments args where
	setArguments :: MessageExpression -> args -> IO ()
	setArguments = setArgument 1
	
-- `tuples' with only one element (not really a tuple)
instance Arguments Char where setArguments = setArgument 1
instance Arguments Int where setArguments = setArgument 1
instance Arguments CString where setArguments = setArgument 1
-- etc ...

-- tuples >= 1 argument
instance (Argument a, Argument b) => Arguments (a, b)
	where
		setArguments expr (a, b) = do
			setArgument 1 expr a
			setArgument 2 expr b
instance (Argument a, Argument b, Argument c) => Arguments (a, b, c)
	where
		setArguments expr (a, b) = do
			setArgument 1 expr a
			setArgument 2 expr b
			setArgument 3 expr c
-- etc ...

-- we can even use existential types to store message arguments,
-- if we want to prove that the Arguments type class can abstract
-- over the data type:
data ExistentialArgument = forall a. Argument a => A a
instance Arguments [ExistentialArgument] where
	setArguments args =
		mapM_ (\(i, a) -> setArgument i expr a) argsWithIndices
			where
				argsWithIndices = zip [1..] args
\end{lstlisting}

Now that an \inline{Arguments} type class has been defined, it is possible to pass arbitrary message arguments to the \inline{sendMessage} function; after creating a new message expression using the C proxy function \inline{makeMessageExpression} defined in \lstrefpage{listing:MessageExpression}, \inline{sendMessage} merely has to call the \inline{setArguments} function to set the arguments in the built message expression.

\subsection{Overloading the message reply type}

Now that \inline{sendMessage} is capable of being called directly with a variable number of message arguments, the last step in implementing the ideal version of \inline{sendMessage} is to make it automatically determine the type of the message reply, and invoke the appropriate \inline{sendMessageExpressionWith\emph{x}Reply} function from \lstrefpage{listing:sendMessageExpressionWithXReply}.

Once again, Lambada\cite{FINN00} has a solution to this ad-hoc polymorphism in the form of its \inline{ComesFromJava} type class; our version is conceptually exactly the same.  We declare a new type class named \inline{MessageReply}, and require any instances of the type class to implement a type-specific version of a generalised \inline{sendMessageExpression} function, as shown in \lstref{listing:sendMessageExpression}.

\begin{lstlisting}[float, caption=The \inline{sendMessageExpression} implementation using a \inline{MessageReply} type class, label=listing:sendMessageExpression]
class MessageReply r where
	sendMessageExpression :: MessageExpression -> IO r

instance MessageReply () where
	sendMessageExpression = sendMessageExpressionWithNoReply
instance MessageReply Int where
	sendMessageExpression = sendMessageExpressionWithIntReply
instance MessageReply CString where
	sendMessageExpression = sendMessageExpressionWithCStringReply
-- etc ...
\end{lstlisting}

\subsection{Implementing and using \inline{sendMessage}}

Finally, it is possible to implement \inline{sendMessage} by building on all the techniques introduced in this section: \lstref{listing:sendMessage} contains the full implementation of \inline{sendMessage}.  Thanks to liberal use of type classes to perform ad-hoc polymorphism, its implementation is (perhaps surprisingly) short and straightforward---especially considering how many lines of code that the function saves from writing, compared to using the low-level interface to send messages.

\begin{lstlisting}[float, caption=The \inline{sendMessage} implementation, label=listing:sendMessage]
sendMessage :: (Arguments args, MessageReply r) =>
	Receiver -> MethodName -> args -> IO r
sendMessage receiver methodName arguments = do
	e <- makeMessageExpression
	setReceiver e receiver
	setMethodName e methodName
	setArguments e arguments
	r <- sendMessageExpression e
	return r

-- pure version of sendMessage (useful for e.g. numeric libraries
-- which are available as objects/components)
sendMessageP :: (Arguments args, MessageReply r) =>
	Receiver -> MethodName -> args -> r
sendMessageP receiver methodName arguments =
	unsafePerformIO (sendMessage receiver methodName arguments)
\end{lstlisting}

\begin{lstlisting}[float, caption=Using \inline{sendMessage}, label=listing:sendMessageUsage]
-- assume that we have the following components declared
numericLibraryComponent :: UniversalObject
networkComponent :: UniversalObject

main = do
	let eighteen = sendMessageP numericLibraryComponent
		"multiply" (3, 6) :: Int
	fileDescriptor <- sendMessage networkComponent
		"openSocket" ("localhost", 6667) :: IO CInt
	sendMessage networkComponent
		"writeString" (fileDescriptor,
			"USER foo localhost localhost :Haskell") :: IO ()
\end{lstlisting}

There are two caveats to the final implementation and usage of \inline{sendMessage} as shown in Listings \ref{listing:sendMessage} and \ref{listing:sendMessageUsage}, compared to our `ideal' version in \lstrefpage{listing:idealSendMessage}:

\begin{enumerate}

	\item The ideal version of \inline{sendMessage} allows for a truly variable number of parameters: one function parameter per message argument.  Our concrete implementation of \inline{sendMessage} requires bundling up all the message arguments into one parameter.

	\item Since \inline{sendMessage}s final type is a (constrained) type variable, we must \emph{fix} the type variable by giving \inline{sendMessage} an explicit type signature whenever it is used; see \lstref{listing:sendMessageUsage} for an example.

\end{enumerate}

Even with these caveats, \inline{sendMessage} is reasonably convenient to use.  It allows sending any arbitrary message to any component, and can receive a reply of any type: it is thus completely dynamic in nature.

\section{Direct Messaging: Statically type-checked message sending}

Recall the definition of \inline{sendMessage} in \lstrefpage{listing:sendMessage}.  While this definition of \inline{sendMessage} is dynamic enough to allow for any type of message to be sent to any receiving object and receive any type of message reply, this dynamism is also a weakness. In a sense, it is \emph{too} dynamic for most purposes: the type system can only assume that the final type for the \inline{sendMessage} function will be \emph{some} type \inline{r}, where \inline{r} could be \emph{any} type which belongs to the type class \inline{MessageReply}.  This has the unpleasant side-effect that whenever the \inline{sendMessage} function is called, the type system must be told explicitly what the reply type will be (i.e.\ the resulting type variable  must be \emph{fixed}), otherwise the type of \inline{sendMessage} will be indeterminate.

It is also necessary to explicitly upcast the receiving object to the \inline{UniversalObject} type, so that the \inline{sendMessage} expression will be well-typed.  This inconvenience is due to a requirement for a messaging function which can communicate with any object: message sending can only work if the receiving object is the \inline{UniversalObject} type, so an explicit upcast is mandatory \emph{somewhere} before \inline{sendMessage} calls the C proxy function to perform the message sending.

A similar problem is that \emph{any objects in the argument list} must also be upcast to the \inline{UniversalObject} type when using \inline{sendMessage}.  Moreover, if the message \emph{reply} is then an object and its type is known at compile-time to be a subtype of \inline{UniversalObject}, an explicit downcast must be performed on the message reply to its known subtype.

As a example, let us examine a typical hashtable container object, which stores an object (a \emph{value}) of type \inline{SomeValue}, which can be retrieved from the hashtable by using another object as a lookup parameter (the \emph{key}).   Compare and contrast the Java (\lstref{listing:hashtableJava}) and Haskell (\lstref{listing:hashtableHaskell}) versions of putting an object anto the hashtable and retrieving it.

\begin{lstlisting}[float, language=Java, caption=Hashtable object manipulation in Java, label=listing:hashtableJava]
aHashtable.put (aKey, aValue);
SomeValue theRetrievedValue = (SomeValue) aHashtable.get (aKey);
\end{lstlisting}

\begin{lstlisting}[float, caption={[Hashtable object manipulation in Haskell using \inline{sendMessage}]Hashtable object manipulation in Haskell using \inline{sendMessage}---the code looks far more verbose than Java!}, label=listing:hashtableHaskell]
sendMessage (upcast aHashtable :: UniversalObject) "put"
	(upcast aKey :: UniversalObject,
	 upcast aValue :: UniversalObject) :: IO ()
valueUniversalObject <- sendMessage
	(upcast aHashtable :: UniversalObject)
	"get" (upcast aKey :: UniversalObject) :: IO UniversalObject
let theRetrievedValue = downcast valueUniversalObject :: IO SomeValue
\end{lstlisting}

It is clear that the Haskell version does not meet the two goals of allowing elegant and convenient communication with components.  Ideally, the Haskell code to perform message sending should be as succinct as possible, so that instead of the tedious usage of \inline{sendMessage} demonstrated by \lstrefpage{listing:hashtableHaskell}, its usage would look more like the code in \lstref{listing:idealHashtableInHaskell}, which is how one would expect to use those functions if there was a Haskell \inline{Hashtable} module which made them available.

\begin{lstlisting}[float, caption=Convenient hashtable component communication in Haskell, label=listing:idealHashtableInHaskell]
put aHashtable (aKey, aValue)
theRetrievedValue <- get aHashtable aKey
\end{lstlisting}

The goal is therefore to have functions which automatically perform any typecasting and type fixing necessary to send a message, so that the programmer does not have to explicitly perform those tasks.  To implement these functions, the dynamic \inline{sendMessage} function can have its dynamism constrained by wrapper functions such as \inline{put} and \inline{get}, when there is knowledge of all the message expression's types at compile-time.  Let us call these static wrapper functions \emph{direct messaging functions}.

\section{Implementing Direct Messaging}

The interface and implementation of the direct messaging functions has four requirements:

\begin{enumerate}

	\item Their usage must be simple and concise, so that they can be used in a manner similar to \lstrefpage{listing:idealHashtableInHaskell}.

	\item Both the type checker and type inference engine must be able to act on all expressions involving direct messaging; i.e.\ allowing ill-typed expressions or introducing inconsistencies in the type system is not permissible.

	\item Whatever scheme is used to implement the direct messaging functions must be reasonably lightweight, so that it is feasible to construct and use thousands of these functions without substantial overhead.

	\item It must be possible to automatically construct every direct messaging function using an interface generator such as \ctohs{} or Template Haskell; it would be senseless to automatically map an entire object-oriented class hierarchy onto Haskell, only to require manual intervention from the programmer when constructing direct messaging functions.

\end{enumerate}

\lstref{listing:putGetImplementations}{} shows a first attempt at writing the \inline{put} and \inline{get} functions.  There are a number of similarities which can be observed in the structure of the functions:

\begin{lstlisting}[float, caption={Implementing the \inline{put} and \inline{get} functions}, label=listing:putGetImplementations]
put :: Instance object
	=> HashtableObject -- hashtable
	-> (object, object) -- key, value
	-> IO ()
put hashtable (key, value) =
	sendMessage (upcast hashtable :: UniversalObject) "put"
		(upcast key :: UniversalObject,
		 upcast value :: UniversalObject)

get :: Instance object
	=> HashtableObject -- hashtable
	-> object -- key
	-> IO UniversalObject -- returned value
get hashtable key =
	sendMessage (upcast hashtable :: UniversalObject) "get"
		(upcast key :: UniversalObject)
\end{lstlisting}

\begin{enumerate}

	\item They are both simple wrapper functions around \inline{sendMessage}; their only task is to call \inline{sendMessage}.
	
	\item Both functions upcast the receiving object and all objects in the argument list to the \inline{UniversalObject} type.
	
	\item Both functions, like \inline{sendMessage}, accept three parameters.
	
	\item Even though \inline{sendMessage} has a type variable for its result type, the \inline{sendMessage} expression here does not need to be given an explicit type signature when it is called.  The type signatures given for the \inline{put} and \inline{get} functions are used by the type system to \emph{fix} \inline{sendMessage}'s free type variable.

\end{enumerate}

\subsubsection*{Automatically upcasting objects in the argument list}

Enabling an object to be sent in the argument list---without explicit upcasting---can be performed by simply making the relevant object data type (\inline{HashtableObject}, in this example) instances of the \inline{Argument} type class described in \lstrefpage{listing:setArgument}.

A lightweight way of doing this for many objects is by declaring a new type class named \inline{ObjectArgument}, which all objects in the class hierarchy are instances of.  \inline{ObjectArgument} implements a \emph{default function} for the type class named \inline{setObjectArgument}, which can then be called by the objects when they are required to implement the \inline{setArgument} function.  \lstref{listing:setObjectArgument} shows the relevant code to do this.

\begin{lstlisting}[float, caption={The \inline{ObjectArgument} type class}, label=listing:setObjectArgument]
class Object arg => ObjectArgument arg where
	setObjectArgument :: Int -> MessageExpression -> arg -> IO ()
	setObjectArgument index expr arg = setUniversalObjectArgument
		index expr (upcast arg :: UniversalObject)

instance ObjectArgument HashtableObject
instance Argument HashtableObject where
	setArgument = setObjectArgument

instance ObjectArgument FiniteMapObject
instance Argument FiniteMapObject where
	setArgument = setObjectArgument
\end{lstlisting}

\subsubsection*{Generalising \inline{put} and \inline{get}}

There is one major problem with \inline{put} and \inline{get}: they only work with a receiving object type of \inline{HashtableObject}.  What if another object-oriented class, e.g. \inline{FiniteMap}, also provided \inline{put} and \inline{get} functions?  In an object-oriented language, each class has a separate name space for method names.  By writing \lstinline[language=Java]{o.m();}, the method name \inline{m} is chosen from within \inline{o}'s method namespace.  Haskell does not have namespace separation between objects, so such a method invocation would be written as \inline{m~o} instead.

Moreover, it is possible to have two classes \inline{Foo} and \inline{Bar}, which both contain a method named \inline{overloadedMethod}---and not only can \inline{overloadedMethod} be overloaded within the class so that it can be called with different types of arguments, but the two classes may contain completely different return types for \inline{overloadedMethod}!  \lstref{listing:overloaded} shows an example of this.  If \inline{overloadedMethod} is made available in Haskell to act as a convenient wrapper for \inline{sendMessage}, what would its type signature be?

\begin{lstlisting}[float, language=Java, caption={\inline{overloadedMethod} in Java}, label=listing:overloaded]
class Foo
{
	// overloaded methods in Java must still have the same
	// return type
	int overloadedMethod (Object o, char c) { ... }
	int overloadedMethod (float f) { ... }
}

class Bar
{
	void overloadedMethod (int i) { ... }
	void overloadedMethod () { ... }
}
\end{lstlisting}

\subsubsection*{Resolving overloading}

In fact, there is already a solution to this problem.  \inline{sendMessage}'s purpose is to send a message to any receiving object, with an arbitrary argument list, and receive with any message reply type.  So, writing an \inline{overloadedMethod} function is a simple exercise of wrapping \inline{sendMessage}, as shown in \lstref{listing:overloadedMethodInHaskell}.

\begin{lstlisting}[float, caption={Implementing \inline{overloadedMethod} in Haskell}, label=listing:overloadedMethodInHaskell]
overloadedMethod ::
	(Object receiver, Arguments args, MessageReply reply)
	=> receiver -> args -> reply
overloadedMethod receiver args reply = sendMessage
	receiver "overloadedMethod" args
	
-- usage (assume Foo and Bar are instances of the
-- appropriate type classes)
data Foo 
data Bar

usage = do
	-- note that we must fix the return type of overloadedMethod,
	-- since its result type is a type variable
	i <- overloadedMethod Foo (anObject, 'c') :: IO Int
	i' <- overloadedMethod Foo (2.69 :: Float) :: IO Int
	overloadedMethod Bar (4 :: Int) :: IO ()
	overloadedMethod Bar () :: IO ()
\end{lstlisting}

Now that implementing a function such as \inline{overloadedMethod} is possible in Haskell, let us once again address the two functions \inline{put} and \inline{get}.  It is possible to implement \inline{put} and \inline{get} similarly to \inline{overloadedMethod}, but if that is done, \inline{put} and \inline{get} will have the same freedom as \inline{overloadedMethod}.  What is required is a way to \emph{constrain} the type variables which \inline{put} and \inline{get} can operate with.  The type checker should produce an error if \inline{put} and \inline{get} are used with an combination of types which have not been specifically permitted.

\inline{put} and \inline{get}'s types can be constrained by using a \emph{multi-parameter type class}, where one parameter is used for each type variable that needs to be constrained.  \inline{put}, \inline{get}, and any other method invocation have three parameters which need to be constrained: the receiving object, the types of the argument list, and the reply type.

Additionally, the type system must be told that the reply type is uniquely determined from the receiving object, otherwise it will not be able to properly \emph{fix} the result type of the \inline{put} and \inline{get} functions.  This can be done by using a Haskell 98 type extension known as \emph{functional dependencies}.  \lstref{listing:putGetConstrained} shows an implementation of \inline{put} and \inline{get}, using multi-parameter type classes with functional dependencies to constrain the types that can be used with the two functions.

\begin{lstlisting}[float, caption={\inline{put} and \inline{get}, allowed only to operate on \inline{Hashtable} and \inline{FiniteMap} receiving objects}, label=listing:putGetConstrained]
class (Object receiver, Arguments args, MessageReply reply) =>
	Put receiver args reply
		-- the reply type is uniquely determined by the receiving
		-- object
		| receiver -> reply

put :: (Put receiver args reply) => receiver -> args -> reply
put = sendMessage (upcast receiver :: UniversalObject) "put" args

class (Object receiver, Arguments args, MessageReply reply) =>
	Get receiver args reply | receiver -> reply

get :: (Get receiver args reply) => receiver -> args -> reply
get = sendMessage (upcast receiver :: UniversalObject) "get" args

-- specifying which types can be used with put and get
instance Put HashtableObject (UniversalObject, UniversalObject) ()
instance Get HashtableObject (UniversalObject) UniversalObject

instance Put FiniteMapObject (UniversalObject, UniversalObject) ()
instance Get FiniteMapObject (UniversalObject) UniversalObject

-- the type checker will disallow the following instance declaration,
-- since otherwise the reply type cannot be uniquely determined
-- from the receiving object.  this is similar to declaring two
-- methods with the signatures "void foo();" and "int foo();" in
-- the same class in Java.
-- 
-- instance Put HashtableObject (UniversalObject, UniversalObject) Int
\end{lstlisting}

\subsubsection*{The \inline{DirectMessage} type class}

\lstref{listing:putGetConstrained}{} shows many similarities between the \inline{Put} and \inline{Get} type classes.  The only difference between them is that the \inline{Put} type class is used to constrain the type variables of the \inline{put} function, and the \inline{Get} type class constrains the type variables of the \inline{get} function.

It is possible to eliminate this requirement of one type class per function by introducing a  \inline{DirectMessage} type class which also includes the \emph{method name} as an additional \emph{phantom parameter}, and declaring a unique \emph{method data type} for each method name.  Each instance of \inline{DirectMessage} uses the method data type in its instance declaration, and each direct messaging function \emph{fixes} the phantom parameter using the method data type.  \lstref{listing:directMessaging} shows how \inline{put} and \inline{get} can be implemented using the \inline{DirectMessage} type class.

\begin{lstlisting}[float, caption={\inline{put} and \inline{get} implemented with the \inline{DirectMessage} type class}, label=listing:directMessaging]
class (Object receiver, Arguments args, MessageReply reply) =>
	DirectMessage receiver methodName args reply
		-- the reply type is uniquely determined by the receiving
		-- object _and_ the method name.
		| receiver methodName -> reply

-- any definition for the method data type is okay; it only
-- matters that the method data type is unique per method name
data MethodName_put
put :: (DirectMessage receiver MethodName_put args reply) =>
	receiver -> args -> reply
put = sendMessage (upcast receiver :: UniversalObject) "put" args

data MethodName_get
get :: (DirectMessage receiver MethodName_get args reply) =>
	receiver -> args -> reply
get = sendMessage (upcast receiver :: UniversalObject) "get" args

-- specifying which types can be used with put and get
instance DirectMessage HashtableObject MethodName_put
	(UniversalObject, UniversalObject) ()
instance DirectMessage HashtableObject MethodName_get
	(UniversalObject) UniversalObject

instance DirectMessage FiniteMapObject MethodName_put
	(UniversalObject, UniversalObject) ()
instance DirectMessage FiniteMapObject MethodName_get
	(UniversalObject) UniversalObject
\end{lstlisting}

This design of using a \inline{DirectMessage} type class is lightweight enough to be used with thousands of direct messaging functions.  Another desirable property of this design is that an automated interface generator will find it trivial to generate the permitted declarations.

One interesting point about the \inline{DirectMessage} class is that is in fact allows for \emph{greater} flexibility in overloading than what would be possible in most object-oriented languages such as Java and C++.  If the functional dependency for \inline{DirectMessage} is modified to \lstinline{receiver methodName args -> reply}, this enables \emph{multiple method definitions in the same class which can have different result types depending on the arguments}.  This is not possible in Java or C++; writing \lstinline[language=Java]|interface Foo { void aMethod(); int aMethod(int i); }| in Java would result in a compile-time error.

\section{Transparent marshalling}

The \inline{Argument} and \inline{MessageReply} type classes enable more than just determining which data types can be sent and retrieved from the component system.  They can perform \emph{transparent marshalling}.  For example, \lstref{listing:transparentStringMarhalling} shows how the Haskell \inline{String} type can be transparently marshalled to and from a \inline{StringObject} before a message is sent or a message reply is retrieved from the component system.

\begin{lstlisting}[float, caption={Transparent \inline{String} $\leftrightarrow$ \inline{StringObject} marshalling}, label=listing:transparentStringMarhalling]
instance Argument String where
	setArgument expr index arg = do
		-- create the string object (by using the direct
		-- messaging function named "new")
		stringObject <- new _StringObject_ arg
		setArgument expr index stringObject
		where
			_StringObject_ = getClassObject
				:: StringObjectClassObject

instance MessageReply String where
	sendMessageExpression receiver methodName args = do
		o <- sendMessageExpressionWithUniversalObjectReply
			receiver methodName args
		let stringObject = downcast o :: StringObject
		-- get the string inside the string object as a C string
		cString <- getCString stringObject
		-- return the CString
		peekCString cString
\end{lstlisting}

\section{Monadic binding and object-oriented syntax}

For clarity, the \inline{sendMessage} function has demonstrated so far with the receiving object as the first parameter in the argument list.  However, it is more advantageous to placing the receiving object \emph{last} in the argument list, because then it is possible to create a new \inline{$\#$} function which allows writing \inline{object $\#$ method} rather than \inline{method object}.  This more closely resembles object-oriented notation.

It is also possible to use the monadic bind operator (\inline{$>>=$}) to permit building \emph{message chains}, where the result of one message expression is used as the \emph{last parameter} to a following message expression.  \lstref{listing:monadicBind} shows the implementation of the \inline{$\#$} function, and \lstref{listing:monadicBindUsage} demonstrates how using \inline{$\#$} and \inline{$>>=$} can lead to compact, object-oriented like code.

\begin{lstlisting}[float, caption={Implementation of the \inline{$\#$} function}, label=listing:monadicBind]
(#) :: object -> (object -> reply) -> reply
object # method = method object
\end{lstlisting}

\begin{lstlisting}[float, caption={Using \inline{$\#$} and \inline{$>>=$} for succinct code}, label=listing:monadicBindUsage]
-- exactly the same implementation of sendMessage shown
-- previously, except that the receiving object is placed
-- as the last parameter instead of the first parameter
sendMessage :: (Arguments args, MessageReply r) =>
	MethodName -> args -> Receiver -> IO r

-- assume that the following methods exist, implemented
-- via direct messaging functions which wrap around
-- sendMessage.  like sendMessage, the receiver in all these
-- functions is also the last parameter.

-- creates a new instance object from a given class object;
-- may return a different type of instance object depending
-- on the type of the class object
new :: (Arguments a, ClassObject c, Instance i) => a -> c -> i
-- retrieves the data at a particular URL
fetch :: Arguments a => a -> URLObject -> DataObject
-- returns the information in the data object as a StringObject,
-- which is automatically marshalled to a String
getContents :: Arguments a => a -> DataObject -> String

-- implementation of a www client in Haskell, using
-- a component system's URL library
main :: IO ()
main = do
	args <- System.getArgs
	-- create a URL from argv[0].  transparent marshalling
	-- is performed, to marshal the given String to the
	-- component system's StringObject type
	url <- _URLObject_ # new (head args)
	-- fetch the URL and retrieve its contents as a String,
	-- again using transparent marshalling to convert the
	-- resulting 
	webpageContents <- url # fetch () >>= getContents ()
	-- display webpage contents to stdout
	putrStrLn webpageContents
	where
		_URLObject_ = getClassObject :: URLClassObject
\end{lstlisting}

\section{Receiving messages}
\label{section:receivingMessages}

For Haskell to act as a first-class citizen in a component system, it must be able to function as a component, and receive and reply to messages as well as send them.

There are two approaches which enable Haskell expressions to be represented as a component.  These parallel the two approaches described in  \sectrefpage{section:representingComponents}:

\begin{enumerate}

	\item The component is represented in Haskell as a data type which is completely  compatible with and indistinguishable from any other component: a Haskell expression \emph{is} a component.
	
	\item A \emph{surrogate} component is written in the proxy language, which is capable of forwarding messages and queries received from component system to the Haskell environment.
	
\end{enumerate}

It is recommended, wherever possible, to use a surrogate component instead of representing the component natively in Haskell, and to perform the actions required to create a component in the proxy language rather than Haskell.  The reasons for this recommendation are the same as the reasons for representing foreign components in Haskell: greater encapsulation and decreased marshalling code.

The interface required of a component and the process of creating and registering a component with the component system are completely dependent on the component system being used.  Even so, it is possible to propose some universal guidelines which are independent of the component system:

\begin{enumerate}

	\item The code to handle incoming messages should be written in the surrogate component where possible.  This decreases the amount of marshalling code which has to be written.
	
	\item There should be a restricted number of entry points into the Haskell environment.  Again, this decreases the amount of marshalling code which has to be written.
	
	\item It may be possible for the surrogate component to marshal all incoming messages as objects.  If this is done, the communications functions defined previously in this chapter can be used to retrieve information from the message, and there only needs to be a single point of entry into the Haskell environment, which is passed the concretised message object as a parameter.  One can define a new \inline{MessageExpressionObject} specifically for this purpose.

	\item Depending on the component system's capabilities, it may be possible to provide a single surrogate object which can masquerade as any object or class in the component system.  The Haskell environment can call functions in the surrogate component to instruct it to act as a particular object in the component system's class hierarchy.  Effectively, the surrogate functions as a \emph{factory object}, and the Haskell environment can create specific instances of the surrogate which gives it the capabilities to act as a particular component.
	
	If it is possible to use the surrogate component as a factory object, this eliminates the need to write different code for each surrogate component.  By using the FFI \inline{foreign import ccall "wrapper"} declaration\footnote{A deprecated form of this declaration is \inline{foreign export "dynamic"}.}, it is possible to provide a pointer to a Haskell function, which each instantiation produced by the surrogate factory object can use to call the Haskell environment.
	
	\item A component written in Haskell requires some way to maintain the state of its instance variables.  This can be done in one of two ways:
	
	\begin{enumerate}
	
		\item An object specifically created for the purpose of storing instance variables can be created.  This \emph{instance variables object} can provide the traditional \inline{get} and \inline{set} methods, parameterised by a \inline{String} to indicate which variable to operate on.  \lstref{listing:haskellComponent} shows how a Haskell component may be written using an instance variables object.
		
		This approach of storing instance variables is therefore capable of storing any Haskell data type which is marshallable to the component system via the \inline{Argument} type class.  While this makes accessing instance variables slightly inconvenient, helper functions can be implemented in a similar fashion to the \inline{Arguments} type class, to perform setting and retrieving on multiple instance variables.  Note that the surrogate component can act as a \emph{factory object} for the instance variables object.
		
		\item Use the fearsome \inline{unsafePerformIO (newIORef \emph{x})} technique\cite{HUGH03} to enable mutable, top-level (global) variables in Haskell.  The use of this technique is neither advocated or disapproved of by this thesis, and there is much debate in the Haskell community\cite{CAFE03} about properties of its usage.
		
	\end{enumerate}
	
\end{enumerate}

\begin{lstlisting}[float, caption={A Haskell component which uses an \emph{instance variables object}}, label=listing:haskellComponent]
-- convenience functions to access instance variables.
-- these declarations could be automatically generated via
-- Template Haskell.
getCounter = getInstanceVariable "counter"
setCounter i = setInstanceVariable ("counter", i)

incomingMessage ::
	MessageExpressionObject -> InstanceVariablesObject -> IO ()
incomingMessage messageExpression instanceVariables
-- initialisation function called by the surrogate component
| messageRequest == "initialise" = -- or "initialize" ...
	instanceVariables # setCounter 42
-- masquerade as a "Counter" object, which only inherits from
-- the root of the class hierarchy
| messageRequest == "class" =
	messageExpression # setReply "Counter"
| messageRequest == "superclass" =
	messageExpression # setReply "Object"
-- methods to increment and decrement the counter
| messageRequest == "increment" = do
	i <- instanceVariables # getCounter
	instanceVariables # setCounter (i + 1)
| messageRequest == "decrement" = do
	i <- instanceVariables # getCounter
	instanceVariables # setCounter (i - 1)
-- returning the current state of the counter
| messageRequest == "getCounter" = do
	i <- instanceVariables # getCounter
	-- the surrogate component can read the value
	-- set in the MessageExpressionObject by the Haskell
	-- environment, and return that value to the component
	-- system.  note that the setReply function is overloaded.
	messageExpression # setReply i
where
	messageRequest = messageExpression # getMessageRequest
		 -- :: String
\end{lstlisting}


%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Exception Marshalling}
%%%%%%%%%%%%%%%%%%%%%%%%%

\emph{Exceptions} are special, pre-defined events which can change a program's execution path.  A division by zero is an example of an exception.  It is possible that sending a message to a component can result in an exception being \emph{thrown} (or \emph{raised}) by the component system.  The thrown exception should then be marshalled to Haskell, so that the Haskell environment can \emph{catch} the exception and take an appropriate action.

How an exception is thrown and caught and how it is represented varies greatly from one component system to the next.  As such, it is the responsibility of the communications functions in the proxy language to correctly catch any exceptions, and marshal it in a form which Haskell can interpret.

To marshal the exception to the Haskell environment, the duty of invoking a message expression is split into two functions:

\begin{enumerate}

	\item The \inline{sendMessageExpression} function shown in \lstrefpage{listing:sendMessageExpression} is modified so that it sends the message but does not return a reply value.  It instead returns an exception object if an exception was thrown, or a \inline{nullPtr} if no exception was thrown.
	
	\item A new function named \inline{getMessageExpressionReply} is defined, to retrieve the message reply from the result of the message expression.
	
\end{enumerate}

\lstref{listing:sendMessageWithExceptions}{} demonstrates the changes which can be made to the appropriate communications functions and type classes.  For comparison, the original implementation of the \inline{sendMessage} function was introduced in \lstrefpage{listing:sendMessage}.

\begin{lstlisting}[float, caption={An implementation of  \inline{sendMessage} which marshals exceptions}, label=listing:sendMessageWithExceptions]
class MessageReply r where
	getMessageExpressionReply :: MessageExpression -> IO r
instance MessageReply () where
	getMessageExpressionReply = return ()
instance MessageReply Int where
	getMessageExpressionReply = getMessageExpressionIntReply
-- etc ...
	
foreign import ccall
	getMessageExpressionIntReply :: MessageExpression -> Int
-- etc ...

foreign import ccall
	sendMessageExpression :: MessageExpression -> IO UniversalObject
	
sendMessage :: (Arguments args, MessageReply r) =>
	Receiver -> MethodName -> args -> IO r
sendMessage receiver methodName arguments = do
	e <- makeMessageExpression
	setReceiver e receiver
	setMethodName e methodName
	setArguments e arguments
	-- see section 5.10 in the FFI addendum for details
	-- on throwIf
	throwIf
		(/= nullPtr)
		(show) -- replace with appropriate marshalling code
		(sendMessageExpression e)
	r <- getMessageExpressionReply e
	return r
\end{lstlisting}


%%%%%%%%%%%%%%%%%%%%%%
\chapter{Memory Management}
%%%%%%%%%%%%%%%%%%%%%%

Haskell features automatic memory management using a \emph{garbage collector}, which is aware of whether any components or objects are no longer being used by the Haskell environment.  The FFI provides a specialised data type to represent objects outside of the Haskell context called a \inline{ForeignPtr}, to which \emph{finalizers} may be attached.  Finalizers are functions which are called when the garbage collector detects that an object is no longer being referenced by the Haskell system.

If a component system uses a \emph{reference counting} scheme to perform memory management, \inline{ForeignPtr}s are a simple way to enable the Haskell system to decrease the reference count of a component when its garbage collector detects it is not being used any more.  In the event that a new object enters the Haskell environment, two steps should be taken.  Firstly, its reference count should be increased if this has not already been done by the component system.  Secondly, the FFI function \inline{newForeignPtr} should be called to attach a finalizer to the pointer and create the foreign pointer.  The finalizer simply decreases the reference count of the object.  If \inline{ForeignPtr}s are used, the \inline{sendMessage} function must also be modified so that it can act on the \inline{ForeignPtr} type; it can use an FFI function such as \inline{withForeignPtr} to obtain the \inline{Ptr} and pass it to the communications functions in the proxy language.

One problem with this scheme is that not every type of object may require manipulation of a reference count.  In particular, class objects provided by the component system are typically present throughout the lifetime of the system, and do not have reference counters associated with them.  This poses a problem for the class hierarchy tree.  The \inline{UniversalObject} type is required to be a \inline{ForeignPtr}, so that any new, unknown objects which enter the Haskell environment can have their reference counts properly decreased when they no longer being used.  However, if class objects are simply \inline{Ptr} types instead of \inline{ForeignPtr} types, then now there are two different types of pointers.  In particular, if \inline{sendMessage} now only works with \inline{ForeignPtr}s, how is it possible to communicate with class objects?  Here are three possible solutions to this problem:

\begin{enumerate}

	\item Two types of \inline{sendMessage} functions can be created: one to send messages to objects represented as \inline{ForeignPtr}s, and one to send messages to \inline{Ptr}s.  The \inline{sendMessage} function which operates on \inline{ForeignPtr}s can easily be implemented using the \inline{sendMessage} function which operates on \inline{Ptr}s\footnote{Note that when the \emph{Ptr} is retrieved from the \inline{ForeignPtr} to be sent, the garbage collector may sense that was the last use of the of the \inline{ForeignPtr}, and execute the attached finalizer \emph{before} the message is sent.  To ensure that this never occurs, either the \inline{withForeignPtr} or \inline{touchForeignPtr} functions should be used appropriately.}.
	
	The class inheritance tree shown in \lstrefpage{fig:classObjectsHierarchy} is modified to include \emph{two} types which may represent any object, as shown in \figref{fig:classObjectsHierarchyWithForeign}: a \inline{UniversalObjectPtr} type which is a \inline{Ptr}, and a \inline{UniversalObject} type which is a \inline{ForeignPtr}.

\begin{figure}[btp]
\centering
\includegraphics[width=\textwidth]{HaskellClassHierarchyWithClassObjectsF}
\caption{A class hierarchy which supports both \inline{ForeignPtr} and \inline{Ptr} data types.  Shapes with solid outlines represent data types, and shapes with dashed outlines represent type classes.  Rectangles indicate data types which are wrappers around \inline{Ptr}s, and ellipses represent data types which are wrappers around \inline{ForeignPtr}s.}
\label{fig:classObjectsHierarchyWithForeign}
\end{figure}

	All class objects are upcast to the \inline{UniversalObjectPtr} type before being used with the version of \inline{sendMessage} that operates on \inline{Ptr}s.  All other objects are upcast to the \inline{UniversalObject} type, for use with the \inline{sendMessage} function that operates on \inline{ForeignPtr}s.
	
	Note that using this design means that there are now \emph{two} data types which can act as the root of the class hierarchy.
	
	\item Any retrieved class objects are upcast to the \inline{UniversalObject} type before they are sent with \inline{sendMessage}, and the casting functions perform the task of converting them from a \inline{Ptr} to a \inline{ForeignPtr} in the process.  The casting functions attaches a \emph{dummy} function as a finalizer, which simply does nothing.

	\item All retrieved class objects are treated as \inline{ForeignPtr}s, with a \emph{dummy} function attached to them as a finalizer.

\end{enumerate}

Each choice has their own advantages and disadvantages, but the recommend approach is to retrieve all class objects as \inline{ForeignPtr}s and attach \emph{dummy} functions as their finalizers.  This approach is preferred for two reasons:

\begin{enumerate}

	\item Using two \inline{sendMessage} functions to handle \inline{Ptr}s and \inline{ForeignPtr}s requires more than one data type to represent the root of the object-oriented class hierarchy.  This is both confusing for programmers and inelegant, since an object-oriented class hierarchy should never have more than one object as the root of a single inheritance tree.  Additionally, there will be different representations of objects in the Haskell environment, so not all objects may be treated similarly by functions which operate on them.
	
	\item Representing retrieved class objects as \inline{Ptr}s and relying on the cast functions to convert between the \inline{Ptr} and a \inline{ForeignPtr} requires the casting functions to be written differently, depending on whether a class object or an instance object is being typecast.  Different representations of objects are also used.
	
\end{enumerate}


%%%%%%%%%%%%%%%%%%%%%%
\chapter{Moch\textbf{$\Lambda$}: Haskell \& Cocoa}
%%%%%%%%%%%%%%%%%%%%%%

\section{Moch$\Lambda$}

The ideas presented in this thesis have been used to implement a language binding between Haskell and Objective-C, named \mocha.  Objective-C uses a small number of extensions to the C language to implement a highly dynamic and reflective object-oriented programming language.  It is used extensively in the Mac OS X, NeXTStep and GNUstep environments, and features two \emph{frameworks}---\emph{Foundation} and \emph{AppKit}---which together allow for very rapid software development.  \emph{Cocoa} is the name that Apple\textregistered{} has given to the combination of the \emph{Foundation} and \emph{AppKit} frameworks in association with several more Objective-C classes specific to the Mac OS X platform.

\subsection{The Cocoa classes}

To model the class hierarchy, \mocha{} generates four class hierarchy trees for the Haskell programmer: one to represent instance objects, one for class objects, one for meta-class objects, and one for Objective-C's \emph{formal protocol} objects\footnote{A \emph{formal protocol} is similar to a Java \emph{interface} or a C++ \emph{pure virtual class}.  Formal protocols enable objects to inherit multiple interface definitions, but not inherit multiple implementation definitions.}.  Class objects can be retrieved by prefixing and postfixing the class name with an underscore, e.g. \inline{\_NSObject\_}, and meta-class objects use two underscores, e.g. \inline{\_\_NSObject\_\_}.  Formal protocol names are appended with \inline{Protocol}, e.g. the Cocoa \inline{NSCoding} protocol is named \inline{NSCodingProtocol} in \mocha.  Formal protocol objects, if they are ever required, can be retrieved using the same \inline{\_\emph{classname}\_} syntax, e.g. \inline{\_NSCodingProtocol\_}.

Interface definitions are provided for the entire Cocoa framework, and on-the-fly interface generation is provided via Template Haskell, so that user-written Objective-C frameworks can easily be used when writing a Haskell program.  (The Template Haskell-based interface generator was also used to generate the interface definitions for Cocoa.)  Instantiating new objects is performed by sending an \inline{alloc} message to a class object, and sending an \inline{init} message to the resulting \inline{alloc}'ed instance object.  Explicit upcasting and downcasting of objects is provided, so that objects retrieved from Cocoa container objects (such as \inline{NSArray} or \inline{NSDictionary}) can be cast appropriately.

\subsection{Communication with Objective-C}

\mocha{} enables Haskell to send messages to Objective-C objects, and also enables Objective-C objects to be written in Haskell.  Sending messages from Haskell to Objective-C uses the same techniques mentioned in this thesis, with the exception that an additional type class has been used in \mocha{} to integrate Objective-C's \emph{type encodings} with the communications functions.

Objective-C method names are encoded in Haskell by lowercasing the first letter and replacing any colons (\inline{:}) in the method name with underscores, omitting the last colon.  For example, the \inline{NSURL} class' initialisation method \inline{initWithScheme:host:path:} is written as \inline{initWithScheme\_host\_path}.

The abstract \inline{MessageExpression} data type used in Chapter \ref{chapter:componentCommunication} is implemented in \mocha{} using the \inline{NSInvocation} class, which exactly fulfils the properties required of a \inline{MessageExpression}.  \mocha{} implements transparent marshalling between Haskell \inline{String}s and the Foundation framework's \inline{NSString} class, and provides \emph{direct messaging functions} for the entire Cocoa framework.

\mocha{} uses surrogate objects to forward messages from the runtime system to the Haskell environment, and these surrogate objects are capable of masquerading as any type of object in Objective-C.  As a result, it is possible for the Haskell environment to respond to actions produced by a user in a GUI interface, or even for Haskell code to function as a fully-fledged \inline{NSDocument} or \inline{NSWindow} controller.  

\subsection{Building Cocoa applications}

The ability of \mocha{} to write Objective-C objects in Haskell enables building complete GUI applications on Mac OS X.  Moreover, \mocha{} provides integration with Apple's Project Builder and Interface Builder programs, which together comprise an \emph{integrated development environment} (IDE) to build Cocoa applications.  This integration enables a programmer to use Interface Builder to build a GUI application's interface, and use Project Builder to directly edit and compile Haskell source code into a resulting application---all within the IDE.  \mocha{} is currently only implemented on the Mac OS X platform, but it should be possible to port it to other Objective-C systems such as GNUstep without much difficulty.

The homepage for \mocha{} is at \url{http://www.algorithm.com.au/mocha/}.  In accordance with the Haskell and Apple open-source developer and research communities, it has been provided under the liberal BSD license.

%%%%%%%%%%%%%%%%%%%%%%
\chapter{Discussion \& Conclusion}
%%%%%%%%%%%%%%%%%%%%%%

\section{Summary of ideas}

The ideas used in this thesis can be used to write a binding from Haskell to a reflective object-oriented programming language or component system.  A complete communications framework has been given which allows low-level messaging functions to be wrapped by elegant, more convenient higher-level \emph{direct messaging} functions.

It is possible to model component system's object-oriented class hierarchy by using the techniques discussed in this thesis.  Objects can be representing in an isomorphic Haskell class hierarchy, it is possible to upcast and downcast objects in the class hierarchy, and  class objects may be represented and used.  To access a particular component's API, a novel approach of using Template Haskell as an \emph{automatic interface generator} has been proposed.

There were also approaches and solutions offered for other important problems, such as transparent type marshalling, enabling components to be written in Haskell, exception marshalling and memory management.  A Haskell to Objective-C language binding, \mocha, has been written, as a concretisation of the ideas in this thesis.  \mocha{} enables a Haskell environment to both communicate with and act as Objective-C objects, and can be used to build full GUI applications on Mac OS X.

\section{Conclusion}

\mocha{} shows that Haskell has much to gain from interacting with object-oriented languages and component systems, by enabling access to rich frameworks and libraries which would otherwise not be available.  As well as simply enabling Haskell to interact with component systems, binding Haskell to these systems also enables programmers that operate in these systems to now use Haskell as an alternative programming language to write components.

\section{Future Work}

Even though this thesis has proposed a practical, universal framework for Haskell to interoperate with component systems, there are still a number of areas where the interoperability may be improved.

\begin{itemize}

	\item Some object-oriented programming languages use \emph{named parameters} to perform function calls or method invocations.  For example, one would write  \lstinline[language={[Objective]C}]{[url initWithScheme:"http" host:"localhost" path:"/"]} in Objective-C to invoke the \inline{url} object's \inline{initWithScheme} method, with the two named parameters \inline{host} and \inline{path}\footnote{This is not quite true---Objective-C does not, strictly speaking, have named parameters.  In this example, the method name is actually \inline{initWithScheme:host:path}, and the parameters for \inline{host} and \inline{path} are passed as normal positional parameters in an argument list.  However, it would still be useful if Haskell could emulate such syntactic sugar which appears much like a function with named parameters.}
	
	It is currently unknown how to provide a convenient, elegant way for Haskell to call functions which use named parameters, so this is an area for future research.  One promising option is a proposal for records in Haskell\cite{RECO03}, which would allow writing \lstinline|url # initWithScheme ("http", { host = "localhost", path = "/" })| to mirror the Objective-C example given above.
	
	\item The syntax to declare a function which can operate on a particular class or type class is slightly inconvenient, since a type variable must specifically be mentioned.  It would be preferable if one could write \lstinline{:: Object -> ...} instead of \lstinline{:: Object o => o -> ...} for a type signature, by using the type system to expand the first type signature to the second.
	
	 \item It would be interesting to use a component system to enable Haskell components to communicate with each other.  Since component systems and some object-oriented frameworks have features such as dynamic loading and network transparency, Haskell could simply use the component system's architecture to allow interaction between different Haskell modules.  For example, using the component system's dynamic loading facilities would enable Haskell to load new components and data types at run-time, and perhaps enable dynamic typing and binding for greater extensibility of Haskell programs.
	 
	 \item When Haskell is used to write components, the two approaches proposed in \sectrefpage{section:receivingMessages} for storing instance variables seem ad-hoc and inelegant.  More research needs to be done on how Haskell components can retain state between invocations of the component.

\end{itemize}

\appendix

\chapter{An explanation of \inline{getClassObject}}
\label{appendix:getClassObject}

The following is an explanation of how the \inline{getClassObject} function, described in \lstrefpage{listing:getClassObject}, works:

\begin{enumerate}

	\item \inline{classObjectName} is called to determine the name of the desired class object.  \inline{classObjectName} knows which name to return since the type of the entire \inline{getClassObject} expression is \emph{fixed} at the point of the function call, by writing \inline{getClassObject :: SubClassObject}.
	
	\item The name returned by \inline{classObjectName} is passed to \inline{getClassObjectFromName}, to obtain the class object for the given name.   The \inline{x} used as the result of the function again \emph{fixes} the result of \inline{getClassObjectFromName}, so it knows exactly the type of the class object to retrieve.
	
	\item The \inline{upcast} function is used to cast the result from a class object data type to the ambiguous type variable \inline{c}, defined in \inline{getClassObject}s type signature.  The type system is able to disambiguate the type variable, since the type of the entire expression has been fixed at the point of the function call.

\end{enumerate}

\lstlistoflistings


%
% Bibliography
%

\backmatter

\begin{thebibliography}{50}

{ \small

\bibitem{FINN99}
Finne, S., Leijen, D., Meijer, E., and Peyton Jones, S.,
\emph{Calling hell from heaven and heaven from hell} (1999),
International Conference on Functional Programming, 1999

\bibitem{FINN00}
Finne, S., and Meijer, E.,
\emph{Lambada, Haskell as a Better Java} (2000),
Haskell Workshop 2000

\bibitem{PEYT98}
Peyton Jones, S., Meijer, E., and Leijen, D.,
\emph{Scripting COM components from Haskell} (1998),
Proceedings of ICSR5

\bibitem{SHIE01}
Shields, M., and Peyton Jones, S.,
\emph{Object-Oriented Style Overloading for Haskell} (2001),
Workshop on Multi-Language Infrastructure and Interoperability (BABEL'01)

\bibitem{C2HS}
Chakravarty, M. M. T.,
\emph{C$\to$Haskell, or Yet Another Interfacing Tool} (1999),
Implementation of Functional Languages, 11th. International Workshop (IFL'99)

\bibitem{HDIR}
Finne, S., Leijen, D., Meijer, E., and Peyton Jones, S.,
\emph{H/Direct: A Binary Foreign Language Interface for Haskell} (1998),
International Conference on Functional Programming, 1998

\bibitem{GTKH}
Chakravarty, M. M. T.,
\emph{A GTK+ Binding for Haskell},
\url{http://www.cse.unsw.edu.au/~chak/haskell/gtk/}

\bibitem{SHEA02}
Sheard, T., and Peyton Jones, S.,
\emph{Template metaprogramming for Haskell} (2002),
Haskell Workshop 2002

\bibitem{LYNA03}
Lynagh, I.,
\emph{Template Haskell: A Report From The Field} (2003),
(unpublished; available at \url{http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/papers/#reportfromfield})

\bibitem{PEYT03}
Peyton Jones, S. (editor), et al.,
\emph{Haskell 98 Language and Libraries: The Revised Report},
\url{http://www.haskell.org/definition/}

\bibitem{HUGH03}
Hughes, J.,
\emph{Global Variables in Haskell},
(unpublished; available at \url{http://www.math.chalmers.se/~rjmh/})

\bibitem{CHAK03}
Chakravarty, M. M. T. (editor), et al.,
\emph{Haskell 98 Foreign Function Interface 1.0: An Addendum to the Haskell 98 Report}
\url{http://www.haskell.org/definition/}

\bibitem{CAFE03}
(members of the \url{haskell-cafe@haskell.org} mailing list)
\emph{Global variables?},
\url{http://haskell.org/pipermail/haskell-cafe/2003-January/003884.html}

\bibitem{RECO03}
Peyton Jones, S., and Morrisett, G.,
\emph{A proposal for records in Haskell}
\url{http://research.microsoft.com/~simonpj/Haskell/records.html}

% \fixme include HOC

}

\end{thebibliography}

\end{document}
