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
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