Proxies and Delegation vs. Existential Types

Haskell may not be especially object-oriented, but all of the core concepts are still there. They just look a little different.

Consider the following problem: you want to manage multiple kinds of "archive" files (e.g. zip, tar.gz, tar.bz2, .tar, etc.). You want to write one function that returns the most appropriate kind of archive, and functions that work on generic archive objects.

The problem is that the type checker forces you to return a concrete type. Something like this isn't allowed past the type checker:

makeArchive :: (Archive a) => String -> a

Why not? Because makeArchive makes no guarantees on what it's returning. Any function that uses it doesn't really know what type it's getting back. Sure, it looks similar to read:


read :: (Read a) => String -> a


Except that the type checker can infer which version of read you're trying to use. If you're expecting to read an integer, the type checker will infer that you want the version of read that returns an integer. If you're expecting to read some indeterminate type, the type checker will tell you give you an error ("Ambiguous type variable..."):

works = do s <- getLine  
           let i = read s
           print (i + 1)  -- read must provide an Int 

doesntWork = do s <- getLine
                let i = read s
                print i   -- no constraint what read provides

The problem is that a function like makeArchive cannot return any instance of a typeclass like Archive, it needs to return a specific type. Another way of looking at it is that you cannot write a version of makeArchive that returns one instance of Archive in one place, and a different instance of Archive in another place. That would be like writing a function that sometimes returns strings, sometimes returns integers, and sometimes returns lists of tuples -- such a function is simply not allowed by the type system.

In object oriented programs, a common solution would be to return a proxy object that delegates all of its operations to some specific object. Fortunately, that's exactly what we need to do in Haskell. All of the necessary types, including the proxy type, will be related to each other because they will be members of the same typeclass:

class Archive a where
  getContents :: a -> [String]
  ...

data ZipArchive = ...
instance Archive ZipArchive where
  getContents = ...

data TarArchive = ...
instance Archive TarArchive where
  getContents = ...

data TarGzArchive = ...
instance Archive TarGzArchive where
  getContents = ...

data TarBz2Archive = ...
instance Archive TarBz2Archive where
  getContents = ...

Next, we need to define a proxy type that will wrap any type that is an Archive. To do this, we need to use existential types:

{-# OPTIONS -fglasgow-exts #-}
data ArchiveProxy = forall a. (Archive a) => ArchiveProxy a
instance Archive ArchiveProxy where
  getContents (ArchiveProxy a) = getContents a

Now, we can write makeArchive to create a specific concrete type (like ZipArchive, TarArchive, or whatnot), and wrap that in the ArchiveProxy constructor to return something of type ArchiveProxy:

makeArchive :: String -> ArchiveProxy
makeArchive fn
  | ".zip" `isSuffixOf` fn = ArchiveProxy (ZipArchive ...)
  | ".tar" `isSuffixOf` fn = ArchiveProxy (TarArchive ...)
  | ...

The value that's returned by makeArchive is opaque, and can perform any methods that are defined by the Archive typeclass. The benefit is that functions can be written in terms of this generic proxy, but always execute the most specific operation for the archive under consideration.

All of this is explained in the Haskell Wiki under existential types, but that discussion approaches the topic from an academic and mathematical perspective. I suspect many professional programmers would be more comfortable with this object oriented view of the world, using proxies and delegates. The terms are different, but the concept is the same.