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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 2533FBBC1 for ; Fri, 25 Apr 2008 19:30:59 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAG+yEUjAXQIm/2dsb2JhbACBU6soAQ X-IronPort-AV: E=Sophos;i="4.25,708,1199660400"; d="scan'208";a="11450712" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 25 Apr 2008 19:30:55 +0200 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m3PHUoHI016323 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 25 Apr 2008 19:30:54 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMAAG+yEUjU436umWdsb2JhbACBU5AGAQEBAQEIBQYJEZpwAQ X-IronPort-AV: E=Sophos;i="4.25,708,1199660400"; d="scan'208";a="25500753" Received: from moutng.kundenserver.de ([212.227.126.174]) by mail4-smtp-sop.national.inria.fr with ESMTP; 25 Apr 2008 19:30:54 +0200 Received: from gate.lan.gerd-stolpmann.de (dslb-088-068-195-048.pools.arcor-ip.net [88.68.195.48]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1JpRkm0qQb-0007Vy; Fri, 25 Apr 2008 19:30:46 +0200 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id CC1CDC074; Fri, 25 Apr 2008 19:30:32 +0200 (CEST) Subject: Re: [Caml-list] [OSR] Standard syntax extensions ? From: Gerd Stolpmann To: Berke Durak Cc: Richard Jones , caml-list In-Reply-To: References: <1209052182.6180.35.camel@Blefuscu> <200804241802.19074.jon@ffconsultancy.com> <20080425082447.GB30805@annexia.org> Content-Type: text/plain Date: Fri, 25 Apr 2008 19:31:39 +0200 Message-Id: <1209144699.13495.16.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19GN9HuShdnHRkpfNdtiFmVZjq3//LSrkellEn viSQmI7fenduM0YmIca2IHzGalArOedxmba36Y9yy+i9Bd1Evn t4W8HOQCRc+6FriFaSKGVSz+Wm2L6Ur X-Miltered: at discorde with ID 4812154A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; syntax:01 gerd:01 stolpmann:01 berke:01 durak:01 0200,:01 berke:01 durak:01 datatypes:01 datatype:01 syntax:01 compiler:01 cmo:01 cmi:01 cmxa:01 Am Freitag, den 25.04.2008, 18:59 +0200 schrieb Berke Durak: > > > On Fri, Apr 25, 2008 at 10:24 AM, Richard Jones > wrote: > On Thu, Apr 24, 2008 at 10:53:36PM +0200, Berke Durak wrote: > > We absolutely need a standard serialization solution. > > > > I'm thinking of Sexplib of course but it could be another > one. The reason > > it must be standard is that it's difficult to provide > > serialization/deserialization functions outside the > imlementation. > > > It isn't though. There are several serialization modules > (sexplib, > deriving, ...), all of them are packaged up so using them is a > simple > 'apt-get' away. > > But we need at least to enrich standard container datatypes with > serialization functions... Do we want to have n copies of each > datatype > for each serialization library? I think we must agree on one such > solution > and ensure it is always available. > > As those solutions all involve syntax extensions, this means that it > must go > into the list of standard sytnax extensions. > > > > So Sexplib should be a standard extension, or better, it > should be included > > in the compiler and used for the .cmo/.cmi/.cmxa files. > > > Why? > > That would allow people to easily write tools that examine object > files without > relying on the unnecessarily britlle binary format. You are very optimistic here. I'm a power user of a number of serializers (JSON, XDR, ICEP), and it is not the problem that one format is binary, and the other text, but that serialized representations are usually not self-describing. So even if you could simply read in a cmi into your program, the problem remains how to interpret it. You cannot overcome the dependency on a certain O'Caml version by switching to a text format. > At the very least you > could open it in a text editor and see if everything's OK inside, or > simply grep > it. You can do that already for cmi's. Just create a file "dummy.ml" with include Name_of_cmi in it and run "ocamlc -c -i dummy.ml" on it which prints the definitions of the cmi as readable text. Ok, there's more in it than only definitions, but the ocaml distribution includes a program called objinfo that allows you to inspect cmi's, cmo's and cma's, e.g. you can view the MD5 sums. > Yes, there is CMI grep, but that one would be even better. Do this, > and > you will instantly see 10 to 20 new metatools for Ocaml. Which tools for example? Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------