hoop

A Haskell library for object-oriented programming which allows programmers to use objects in ordinary Haskell programs. In particular, the library achieves the following design objectives (to avoid ambiguity with Haskell's type classes, we refer to classes in the object-oriented sense as object classes):

• No extensions to the Haskell language are required beyond what is already implemented in GHC. Object classes are generated from Template Haskell quasi quotations using an OO-like syntax where the methods are defined as ordinary Haskell expressions.
• Object classes can be instantiated from ordinary Haskell code (with an overloaded function named new). The resulting objects are ordinary Haskell values and can be used as such.
• Calling methods on objects can be done from within ordinary Haskell code.
• The objects do not rely on IO. Instantiating objects and calling methods on the resulting objects is pure.
• Object classes can inherit from other object classes, which also established subtyping relations between them. There is no limit to how deep these inheritance trees may grow.
• Class hierarchies are open for extension. I.e. the library does not need to know about all subclasses of a given class in order to generate the code for that class, allowing modular compilation.
• Casting from subtype objects to their supertypes is supported and the types are correctly reflected in Haskell's type system (e.g. assuming that we have Duck <: Bird and that obj :: Duck then upcast obj :: Bird) and pure.
• Type annotations are generally not required except where something would logically be ambiguous otherwise (e.g. instantiating an object with the new function).

Examples

The test folder contains a number of examples of the library in action, illustrating the various features.

As a quick tutorial, a simple expression language can be implemented using the library as shown below. Note that the bodies of the two implementations of the eval method are ordinary Haskell expressions. The .! operator is an ordinary Haskell operator used to call methods on objects and this is just an ordinary Haskell definition, too.

[state|
abstract state Expr where
    eval :: Int

state Val : Expr where
    data val = 0 :: Int

    eval = do
        r <- this.!val
        return r

state Add : Expr where 
    data left :: Expr 
    data right :: Expr 

    eval = do 
        x <- this.!left.!eval 
        y <- this.!right.!eval 
        return (x+y)
|]

someExpr :: Add 
someExpr = new @Add (upcast $ new @Val 4, upcast $ new @Val 7)

someExprResult :: Int 
someExprResult = result (someExpr.!eval)

If we evaluate someExprResult, the result is 11 as expected. We can note some points of interest here that differ from popular object-oriented programming languages:

• The type annotations on someExpr and someExprResult are optional and just provided for clarity. The type applications for the calls to new are required (alternatively, type annotations on the sub-expression would work, too).
• Casts must be explicit: in the example, the objects of type Val must be explicitly cast to Expr values to instantiate the Add object.
• Since everything is pure, calling a method on an object produces two results: the result of the method call and a (potentially) updated object. The result function returns the result of calling eval on the someExpr object, discarding the resulting object.
• It does not matter what type of object we call eval on, as long as it is of type Expr or is a sub-type of Expr.

Indeed, we can cast the Add object to an Expr object, call eval on it, and still get the correct result:

> let e = upcast someExpr in result (e.!eval)
11

• Casting from supertype objects to a subtype is possible, but may fail (returning Nothing). E.g. assuming Duck <: Bird and that obj :: Bird then downcast obj :: Maybe Duck.

Overview of the process

• QuasiQuoters.hs contains the entry point
• First, the state declarations are parsed (Parsers.hs) via parseStateDecl
• The parsed declarations are then passed to genStateDecls (Language.MSH.CodeGen.Decls / Decls.hs)
• This turns the declarations into a dependency graph (via buildStateGraph in Language.MSH.StateEnv / StateEnv.hs)
• If successful, the graph is written to graph.log
• The genStateDecl function is then applied to every state declaration in dependency order (i.e. starting from no dependencies)