This lets the compiler (and programmer!) recognize phantom types and ensure they aren't used improperly.
1 Simple examples
A data type that uses phantom types will often look something like this:
data FormData a = FormData String
This looks strange since at first it seems the type parameter is unused and could be anything, without affecting the value inside. Indeed, one can write:
changeType :: FormData a -> FormData b changeType (FormData str) = FormData str
data Validated data Unvalidated -- since we don't export the constructor itself, -- users with a String can only create Unvalidated values formData :: String -> FormData Unvalidated formData str = FormData str -- Nothing if the data doesn't validate validate :: FormData Unvalidated -> Maybe (FormData Validated) validate (FormData str) = ... -- can only be fed the result of a call to validate! useData :: FormData Validated -> IO () useData (FormData str) = ...
-- the library exports this liftStringFn :: (String -> String) -> FormData a -> FormData a liftStringFn fn (FormData str) = FormData (fn str) -- the validation state is the *same* in the return type and the argument dataToUpper :: FormData a -> FormData a dataToUpper = liftStringFn (map toUpper)
With type classes, we can even choose different behaviours conditional on information that is nonexistent at runtime:
class Sanitise a where sanitise :: FormData a -> FormData Validated -- do nothing to data that is already validated instance Sanitise Validated where sanitise = id -- sanitise untrusted data instance Sanitise Unvalidated where sanitise (FormData str) = FormData (filter isAlpha str)
This technique is perfect for e.g. escaping user input to a web application. We can ensure with zero overhead that the data is escaped once and only once everywhere that it needs to be, or else we get a compile-time error.
2 The use of a type system to guarantee well-formedness.
We create a Parameterized type in which the parameter does not appear on the rhs (shameless cutting and pasting from Daan Leijen and Erik Meijer)
data Expr a = Expr PrimExpr constant :: Show a => a -> Expr a (.+.) :: Expr Int -> Expr Int -> Expr Int (.==.) :: Eq a=> Expr a-> Expr a-> Expr Bool (.&&.) :: Expr Bool -> Expr Bool-> Expr Bool data PrimExpr = BinExpr BinOp PrimExpr PrimExpr | UnExpr UnOp PrimExpr | ConstExpr String data BinOp = OpEq | OpAnd | OpPlus | ...
i.e. the datatype is such that we could get garbage such as
BinExpr OpEq (ConstExpr "1") (ConstExpr "\"foo\"")
but since we only expose the functions our attempts to create this expression via
constant 1 .==. constant "foo"
would fail to typecheck
I believe this technique is used when trying to interface with a language that would cause a runtime exception if the types were wrong but would have a go at running the expression first. (They use it in the context of SQL but I have also seen it in the context of FLI work.)
A foundation for embedded languages provides some formal background for embedding typed languages in Haskell, and also its references give a fairly comprehensive survey of uses of phantom types and related techniques.