6.2 Representing Haskell COM objects

The goal is to be able to expose Haskell code as COM component functionality, so how should we represent such an object in Haskell? We've more or less given the solution away for the kind of representation we prefer in Section Implementing COM components in Haskell, but there's a couple of possible choices:

• All methods of the object are IO actions that take the object state as their first argument:

  module IntRef where
  type State = IORef Int
  get :: State -> IO Int
  set :: State -> Int -> IO ()
  new :: IO State
  

  which they then are responsible for explicitly updating when invoked. A variation on this is to instead return the updated state:

  module IntRef where
  type State = Int
  get :: State -> IO (Int, State)
  set :: State -> Int -> IO State
  new :: IO State
  

  but the advantages of this scheme over the first one are few (if any).
• No constraints on how methods are implemented, instead rely on the object constructor to package them up:

  module IntRef where 
  
  type IntRefMethods = 
    ( Interface IIntRef -> Pointer Int -> IO HRESULT -- getter
    , Int -> Interface IIntRef -> IO HRESULT         -- setter
    )
  new :: IO IntRefMethods
  new = do
    var <- newIORef 0
    let
     set' v _ = do
       writeIORef var v
       return s_OK
     get' _ ptr = do
        v <- readIORef var
        if ptr == nullAddr 
         then return e_POINTER
         else do
           writeIntOffAddr ptr v
           return s_OK
    return (set',get')
  

Discussion:

• The first representation is just the ticket for IntRef.
• The second representation allows you to easily insert arbitrary marshalling between expected method type signature and method implementation.
• For the second representation, in the event that the methods need to use their interface pointer, it is passed as an argument to all the methods in the dict. The dict methods are also responsible for passing back status codes (HRESULTs.)
• Passing the object state explicitly to the methods has a performance benefit over the other rep., since the name of the Haskell action that the corresponding stubs will invoke is statically known.
• The dictionary representation requires the programmer to write a constructor that returns a dictionary of identical shape to what the stub code expects. This is probably not such a big bug farm, since the author of the constructor is also likely to write the IDL spec.

The following sections assume that the explicit state representation is used.