Reflection API for Haskell.

[Krasimir Angelov]

Sure. The proposal isn't final. I already have found that it needs
extra work. As you said it will require representation for 'forall'.
The 'tyConArity' function is totally wrong, instead we will need
'tyConKind' function which have to return the complete type kind.
Another difficulty is that the following declarations:

data T1 = mkT1
data T2 = mkT2 T1 deriving Typeable

are correct with the existing Typeable but with the proposed
extensions we will need Typeable instance for T1 too. This is because
in order to represent the type of mkT2 :: T1 -> T2 we need the TypeRep
of T1 and hence we need Typeable T1. This will make the proposal
backward incompatible. Instead we can leave the DataCon representation
in the Data class but with some revisions.

2006/4/3, Simon Peyton-Jones <simonpj at microsoft.com>:
> The water seems deeper here.  Are you sure you could not get away
> without representations of the constructor argument types?  After all,
> SYB has already shown how to write serialisers and deserialisers.

It isn't enough because I would like to be able to
serialize/deserialize some Haskell values to BerkleyDB. The existing
API is enough for that but the troubles come when I have to change the
representation of any type. I would like to compare the current type
representation with those stored in the database. In addition I would
like to have generic tool that will be able read\write data from the
database without need to have the same data types defined. This is
necessary if you want to have an easy way to translate your exising
data to the new representation.

Cheers,
  Krasimir