Re: [Caml-list] Marshalling: automatic discard of unmashalable data via

[oleg@okmij.org]

> The system state is made of pretty much anything, and is also user
> extensible via plugins.  Nothing prevents someone to stick in there
> values that can hardly be marshalled, like callbacks, file descriptors,
> lazy_t, and the like.  Of course it is nice to be able to store
> callbacks or lazy values in the system state, so forbidding all that is
> not nice.

There is a similar problem when marshalling a captured delimited
continuation. The continuation captures a part of stack that points to
various closures in system libraries, which contain lots of
unserializable stuff. In addition, reference cells (t ref) can't be
meaningfully serialized as they are copied in the process of the
serialization, which breaks their semantics. 

The library delimcc proposes a solution. Unlike your situation, I do
care to properly serialize `bad' value and properly restore. The
unmarshalled delimited continuation must work properly. I cannot
afford not to care what the unmarshalled value will look like.

The solution, which involves pre-processing a value before marshalling
and post-processing after unmarshalling, is described at
        http://okmij.org/ftp/ML/ML.html#persistent-delim2cc
as well in Sec 8 of
        http://okmij.org/ftp/continuations/caml-shift-journal.pdf