From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 9FC15BBCA for ; Fri, 29 Feb 2008 15:45:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADupx0dCbwQbmGdsb2JhbACQcAEBAQEBBgQGBwoWnEY X-IronPort-AV: E=Sophos;i="4.25,426,1199660400"; d="scan'208";a="23209117" Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Feb 2008 15:45:44 +0100 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id BD7BFA7BCF; Fri, 29 Feb 2008 09:45:41 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 29 Feb 2008 09:45:41 -0500 X-Sasl-enc: eeTkvcYs7B+IDQ6B9KF8ci92yv1tR639WOyPpcFvsISe 1204296341 Received: from [192.168.1.12] (ALyon-157-1-57-80.w81-251.abo.wanadoo.fr [81.251.24.80]) by mail.messagingengine.com (Postfix) with ESMTPSA id D756E18878; Fri, 29 Feb 2008 09:45:40 -0500 (EST) Date: Fri, 29 Feb 2008 15:45:21 +0100 (CET) From: Martin Jambon X-X-Sender: martin@martin.ec.wink.com To: Basile STARYNKEVITCH Cc: Dario Teixeira , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Long-term storage of values In-Reply-To: <47C73121.2060809@starynkevitch.net> Message-ID: References: <191751.36007.qm@web54607.mail.re2.yahoo.com> <47C73121.2060809@starynkevitch.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam: no; 0.00; ens-lyon:01 basile:01 ocaml:01 moscova:01 arrays:01 subset:01 camlp:01 arbitrarily:01 foo:01 foo:01 nodes:01 closures:01 closures:01 wrote:01 wrote:01 On Thu, 28 Feb 2008, Basile STARYNKEVITCH wrote: > Dario Teixeira wrote: >> Hi, >> >> Suppose I have a value of type Story.t, fairly complex in its definition. >> I wish to store this value in a DB (like Postgresql) for posterity. >> At the moment, I am storing in the DB the marshalled representation >> of the data; whenever I need to use it again in the Ocaml programme >> I simply fetch it from the DB and unmarshal it. >> >> This works fine; there is however one nagging problem: the marshalled >> representation is brittle. If Story.t changes even slightly, I will >> no longer be able to retrieve values marshalled with the old version. > > > It is even theoretically a very difficult problem. There have been some > publications by Cristal, Moscova, Gallium people at INRIA. > > Assuming you have no abstract types, no objects, and no closures, and no > polymorphisms i.e. that there is a *.ml source file containing all the type > definitions. Then the types are composed by base types (int, string, ...), > sums, records, and perhaps arrays. > > Then you could consider what are the deltas on the type definition. > > In a sum like type sumt = A of t1 | B of t2 | C > you might consider what happens when you remove let say B, or add let's say a > choice | D of t3 > > In a record, consider likewise what happens when adding or removing a field. > > Etc.... > > > The details are very complex (at least to me, who tried unsucessfully to work > on this during my year at INRIA). > > Maybe a semi-hand-crafted generator could help. Adding polymorphisms, > closures, objects, abstract types is a big mess. I sure do believe you. However, speaking with no experience in this domain, it seems to me that if we restrict the transition to a certain subset of operations, it can be possible to define a mapping using some Camlp4 tool such as Deriving (well, that's what I was told, assuming I interpreted correctly). For instance: - adding a record field: a default value is injected - removing a record field: just remove it - adding a variant: do nothing since it doesn't exist in the old data - changing a type arbitrarily (such as changing a type foo1 into foo2 everywhere): provide a map function that would override the default map function for such nodes. - functional and abstract values: left as-is I think I'll soon have to deal with such a problem, so any further suggestions are welcome. Martin -- http://wink.com/profile/mjambon http://martin.jambon.free.fr