From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id CCCC2BB9C for ; Thu, 15 Sep 2005 18:55:25 +0200 (CEST) Received: from copper.three-tuns.net (copper.three-tuns.net [193.201.200.235]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8FGtP5S009699 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 15 Sep 2005 18:55:25 +0200 Received: from mark by copper.three-tuns.net with local (Exim 4.52) id 1EFx1A-0005U4-Ez; Thu, 15 Sep 2005 17:55:24 +0100 Date: Thu, 15 Sep 2005 17:55:24 +0100 From: Mark Shinwell To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Marshal.to_string and mutable values Message-ID: <20050915165524.GH5470@three-tuns.net> References: <005201c5ba04$1797ff80$0100a8c0@mshome.net> <20050915151309.GA14311@kruemel> <005f01c5ba0d$2048a4a0$0100a8c0@mshome.net> <200509151654.46707.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509151654.46707.jon@ffconsultancy.com> User-Agent: Mutt/1.5.9i Sender: Mark Shinwell X-Miltered: at nez-perce with ID 4329A77D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; shinwell:01 shinwell:01 caml-list:01 mutable:01 gava:01 toplevel:01 pointer:01 pointer:01 toplevel:01 o'caml:01 damien:01 pointers:01 pointers:01 traversing:01 runtime:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Thu, Sep 15, 2005 at 04:54:46PM +0100, Jon Harrop wrote: > On Thursday 15 September 2005 16:49, Fr?d?ric Gava wrote: > > ok. Excuse me for this stupid question (but the error messages are not > > clear). My true question is: why does it not work in the toplevel ? > > Marshal probably marshals the environment of a closure with a pointer to the > position of the code (the code itself is not available to Marshal). Clearly, > that pointer only makes sense in a compiled program and not in the top-level, > e.g. when loading your marshalled value from a fresh top-level, your function > does not exist. It is indeed a problem relating to a disparity between the toplevel and the compiled versions, but the failure is not for the above reason. I encountered the same problem, albeit from a different angle[*], during the implementation of Fresh O'Caml some months ago. At that time I asked Damien Doligez about it and he said: "When the toplevel compiles code on the fly, the resulting code is not recognized as such by the Marshal module, but the code pointers in the closures are seen as generic out-of-heap pointers, and trigger the Invalid_argument exception." Even so, I still don't fully understand why this is the case (perhaps someone could elaborate? ;) Mark [*] Traversing arbitrary values at runtime.