From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oleg@okmij.org>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 972137EE25
	for <caml-list@sympa.inria.fr>; Tue, 22 Oct 2013 11:38:57 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  oleg@okmij.org) identity=pra; client-ip=66.39.3.115;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  oleg@okmij.org designates 66.39.3.115 as permitted sender)
  identity=mailfrom; client-ip=66.39.3.115;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@www1.g3.pair.com) identity=helo;
  client-ip=66.39.3.115;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="oleg@okmij.org";
  x-sender="postmaster@www1.g3.pair.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgEAIxGZlJCJwNzYGdsb2JhbABZgz+/FYE8AxgHFjyCJQEBAwEBeQUWNGkUIIdlBg26c4xyglQHFoQTA5gIAYEvk3w8
X-IPAS-Result: ApgEAIxGZlJCJwNzYGdsb2JhbABZgz+/FYE8AxgHFjyCJQEBAwEBeQUWNGkUIIdlBg26c4xyglQHFoQTA5gIAYEvk3w8
X-IronPort-AV: E=Sophos;i="4.93,547,1378850400"; 
   d="scan'208";a="38187541"
Received: from www1.g3.pair.com ([66.39.3.115])
  by mail2-smtp-roc.national.inria.fr with SMTP; 22 Oct 2013 11:43:49 +0200
Received: (qmail 29320 invoked by uid 9370); 22 Oct 2013 09:38:54 -0000
Date: 22 Oct 2013 09:38:54 -0000
Message-ID: <20131022093854.29319.qmail@www1.g3.pair.com>
From: oleg@okmij.org
To: enrico.tassi@inria.fr
CC: caml-list@inria.fr
In-reply-to: <20131014153023.GA19032@birba.invalid>
Subject: Re: [Caml-list] Marshalling: automatic discard of unmashalable data
 via


> 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