The data Dynamic -- abstract, instance of: Show -- toDyn :: Typeable a => a -> Dynamic fromDyn :: Typeable a => Dynamic -> a -> a fromDynamic :: Typeable a => Dynamic -> Maybe a There's two ways of going from a dynamic value to one with a concrete type: The

Haskell types are represented as terms using the data TypeRep -- abstract, instance of: Eq, Show data TyCon -- abstract, instance of: Eq, Show mkTyCon :: String -> TyCon mkAppTy :: TyCon -> [TypeRep] -> TypeRep mkFunTy :: TypeRep -> TypeRep -> TypeRep applyTy :: TypeRep -> TypeRep -> Maybe TypeRep Type constructors are represented by the abstract type, Most importantly, To allow comparisons between mkTyCon :: String -> TyCon An implementation of the mkTyCon "a" == mkTyCon "a" A really efficient implementation is possible if we guarantee/demand that the strings are unique, and for a particular type constructor, the application Would this constraint be unworkable in practice? Both The Typeable class

To ease the construction of class Typeable a where typeOf :: a -> TypeRep The The Prelude types: Int, Char, Bool, Float, Double, Integer, (IO a), [a], (Either a b), (Maybe a), (a->b), (), (,), (,,), (,,,), (,,,,), Ordering, Complex, Array, Handle Hugs/GHC types: Addr, Word8, Word16, Word32, Word64, Int8,Int16,Int32,Int64, ForeignObj, MVar, (ST s a), (StablePtr a) GHC types: Word, ByteArray, MutableByteArray

Operations for applying a dynamic function type to a dynamically typed argument are commonly useful, and also provided: dynApply :: Dynamic -> Dynamic -> Dynamic -- unsafe. dynApplyMb :: Dynamic -> Dynamic -> Maybe Dynamic