Some technical information about the current implementation of serialization may be in order:
As long as no procedures or continuations are serializated, it shouldn't be too hard to add more robustness and portability to its format. But once procedures enter the scene things can get so ugly, that I ask me whether it makes sense to actually even try to approach portability. Currently, when chicken is configured with --enable-procedure-tables, a static array is generated for each file/unit that holds a string ID (made from the internal "lambda"-ID, which is locally unique and the source file-name) and a void* to the procedure/continuation code. Compiling the same file with different compiler versions, compiler options or only a few procedures more or less will shift the lambda-ID counter arbitrary, so any serialized data refering to the older set of IDs will not work or worse, will work and fail for weird reasons. Now, one could go to great lengths about ensuring more robustness here, but I wonder if it's worth the trouble. As long as serialization is used for quick, local, short-range communiation, or communication of a rigidly controlled set of machines one might be able to handle the needed steps of keeping the code-base in sync. Another example is locally storing session-data (i.e. web-servers). But for larger-scale communication, or communication across a heterogenous network, I highly recommend S-expressions, which are just as portable as XML, but need less bandwidth (and are easier to parse). cheers, felix _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users