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=3.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 1ED08BBAF for ; Fri, 24 Oct 2008 01:37:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjADAMimAEnVBJXyb2dsb2JhbACBdpF6AQwKCwcPBa5hg04 X-IronPort-AV: E=Sophos;i="4.33,473,1220220000"; d="scan'208";a="18438605" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 01:37:02 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9NNasA1001889 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2008 01:37:02 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjADAMimAEnVBJXyb2dsb2JhbACBdpF6AQwKCwcPBa5hg04 X-IronPort-AV: E=Sophos;i="4.33,473,1220220000"; d="scan'208";a="18438603" Received: from outmailhost.telefonica.net (HELO ctsmtpout3.frontal.correo) ([213.4.149.242]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2008 01:37:02 +0200 Received: from NANA.localdomain (83.59.9.219) by ctsmtpout3.frontal.correo (7.3.135) (authenticated as ferferse$telefonica.net) id 48F8E066002D8896; Fri, 24 Oct 2008 01:36:58 +0200 Received: from mfp by NANA.localdomain with local (Exim 4.69) (envelope-from ) id 1Kt9jd-0005ar-Om; Fri, 24 Oct 2008 01:36:57 +0200 Date: Fri, 24 Oct 2008 01:36:57 +0200 From: Mauricio Fernandez To: Dario Teixeira Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Serialisation of PXP DTDs Message-ID: <20081023233657.GE32611@NANA.localdomain> Mail-Followup-To: Dario Teixeira , caml-list@inria.fr References: <20081023210527.GB32611@NANA.localdomain> <278256.11946.qm@web54605.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <278256.11946.qm@web54605.mail.re2.yahoo.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Miltered: at concorde with ID 49010A96.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; pxp:01 dtds:01 compiler:01 ocaml:01 ocaml:01 haskell:01 syntax:01 syntax:01 sexp:01 entail:01 compiler:01 ocaml's:01 camlp:01 ocaml's:01 subset:01 On Thu, Oct 23, 2008 at 03:21:01PM -0700, Dario Teixeira wrote: > Hi, > > > This protocol definition is fed to the compiler, which > > generates the OCaml type definitions, as well as the > > encoders/decoders and pretty-printers (as you can see, > > the specification uses a mix of OCaml, Haskell and C++ > > syntax, but it's pretty clear IMO) > > Basically the XDR approach, but with a syntax inspired > by more modern, functional languages, right? Yes, something like XDR (and Google's Protocol Buffers, and Facebook's Thrift, and and :) with richer data types (algebraic and polymorphic types, etc.) and a self-describing encoding that allows you to extend the type definitions while ensuring interoperability. > > It's not a drop-in solution like sexplib's "with sexp", > > by design (since it is meant to allow interoperability between > > different languages), but it's still fairly easy to use. > > Personally, I think that a sexplib-like syntax extension is the killer > feature for serialisation libraries, and the reason why I was immediately > swayed by sexplib. However, writing a sexplib-like syntax extension for > your serialisation library would entail solving the reverse problem now > handled by your compiler. This might not always be possible because some > features of Ocaml's type system might not map neatly into your format. > Nevertheless, the sheer convenience of the syntax extension approach makes > it worth while having, even if on occasion the preprocessor were to produce > an error message stating that it could not convert a certain structure. For > reference purposes, you could even have the syntax extension output to an > external file the inferred structure definition in your language format! (I > know this would be a very complex project, but it does illustrate the power > of Camlp4). In fact, the wire format easily supports all of OCaml's type system (bin-prot does, after all, and this is essentially a self-describing, extensible bin-prot). I introduced limitations in the data schema to ensure extensibility and portability. Any OCaml type can be encoded easily, but not all possible changes to an OCaml type are safe with regard to protocol compatibility. Using a separate language makes it easier to prevent altogether (by making them impossible to express) or catch such errors. Leaving unsafe protocol modifications aside (which just means that you have to be careful when you change a type), the approach you suggest (supporting only a subset of OCaml's type system in a "with protocol"-style syntax extension) seems very doable. However, sexplib seems to be the safest option for convenient, more or less future-proof serialization in OCaml, for the time being. Cheers, -- Mauricio Fernandez - http://eigenclass.org