Krasimir Angelov schrieb:
All those libraries really force the data because they all are written in Haskell. If you want to serialize thunks then you will need some support from RTS.
Good to hear that my conjectures aren't too far from reality. Does any Haskell implementation have that kind of RTS support?
The serialization of thunk requires to store a reference to procedure for thunk evaluation. After that it is tricky to do the deseriazation because you will have to dynamically link the thunk evaluation code.
Actually, I'd be happy if the deserializing program were required to contain the same code that serialized the thunk. Technically, I think that could be achieved by generating checksums over a suitably normalized version of the source code. Or, for a bytecode-based RTS, one could simply store the bytecode for each thunk (with proper sharing, of course).
The program that do the serialization and the program that have to read it aren't necessary one and the same program.
Indeed. There is little need to change data structures and have versioning unless the code that uses the data changes.
In this case the reading application should have some way to call code from the writing application.
Yup. It may be kept in the old executable, or stored in the marshalled data (I think that's what Mozart/Oz is doing).
Another problem arises when you have to recompile the writing application. After the recompilation the evaluation code for some thunk may not exist any more. The solution that Clean is using is to keep a copy of each executable after each compilation.
I wouldn't mind if I had to explicitly manage old versions of the code. I'll never have data that's more than one version old, and that can be managed using a simple script. Regards, Jo