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