Reflection API for Haskell.

[Krasimir Angelov]

Hello Guys,

I am interested in having better Reflection API for Haskell. Currently
we have Typeable and Data classes which provide some pieces of
information about the data types at runtime. The (typeOf :: Typeable a
=> a -> TypeRep) method provides runtime information about the type of
a given variable. The (dataTypeOf :: Data a => a -> DataType) provides
almost the same information but with some extras. There is some
overlap between the TypeRep and DataType types. Some pieces of
information you can get from the TypeRep, other from the DataType and
some other from both of them. There is also an information which is
inaccessible from either TypeRep and DataType. Here is a list of the
differences:

- TypeRep contains both the TyCon and the arguments given to it.
DataType contains only the name of the TyCon. The TyCon name is
duplicated in TypeRep and in DataType.
- DataType contains the DataRep structure which gives us an
information about the available data structures. This is the only way
to access them.
- The Constr type represents data constructors at runtime. It has
information about the constructor name, the record selectors and the
fixity (prefix/infix). Unfortunately there isn't any information about
the types of its arguments.

What I would like to see is a better Reflection API with clear
interface. My proposal is:

-- * Type representations
TypeRep -- abstract, instance of: Eq, Show, Typeable
TyCon -- abstract, instance of: Eq, Show, Typeable
DataCon   -- abstract, instance of: Eq, Show, Typeable

-- * Construction of type representations
mkTyCon       :: String  -> Arity -> [DataCon] -> Fixity -> TyCon
mkTyConVar  :: Int -> Arity -> TyCon
mkTyVar      :: Int -> TypeRep
mkTyConApp :: TyCon   -> [TypeRep] -> TypeRep
mkDataCon   :: String -> [TypeRep] -> TypeRep -> [String] -> Fixity -> DataCon

-- * Fixity representation
Fixity(..)        -- instance of: Eq, Show, Typeable
defaultFixity  :: Fixity

-- * Observation of type representations
typeRepTyCon :: TypeRep -> TyCon
typeRepArgs    :: TypeRep -> [TypeRep]

-- * Observation of type constructors
tyConString       :: TyCon   -> String
tyConArity         :: TyCon   -> Int
tyConDataCons  :: TypeCon -> [DataCon]
tyConFixity        :: TyCon   -> Fixity

-- * Observation of data constructors
dataConString  :: DataCon -> String
dataConArgs    :: DataCon -> [TypeRep]
dataConResult :: DataCon -> TypeRep
dataConFields :: DataCon -> [String]
dataConFixity  :: DataCon -> Fixity

The above API is just a reorganization of the existing API but with
some extensions:

- In the existing API there is no way to get the TyCon fixity and
arity. In the new one there are the tyConFixity and tyConArity
functions.
- The data constructors are available from the tyConDataCons function.
There isn't need for the separated DataType and DataRep types.
- The DataCon arguments and the result type are available from the
dataConArgs and dataConResult functions.
- Since the type can be polymorphic we need to have representation for
type variables. For that reason there are the mkTyVar and mkTyConVar
functions.

The new API can be used for both the Dynamic data type implementation
and for the generic programming API. The additional information can be
used for many kinds of serialization libraries where you would like to
be sure that you are deserialising data with the same structure as
those used in your program. In addition if you have stored the data
type meta information you can have many kinds of generic tools that
can read/write the data without need to have the same types defined in
the application.

What do you think about this kind of generalization of the existing
API in the standard package?

Cheers,
  Krasimir