Version française
Home     About     Download     Resources     Contact us    
Browse thread
[OSR] Standard syntax extensions ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] [OSR] Standard syntax extensions ?

Am Freitag, den 25.04.2008, 18:59 +0200 schrieb Berke Durak:
> 
> 
> On Fri, Apr 25, 2008 at 10:24 AM, Richard Jones <rich@annexia.org>
> 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
------------------------------------------------------------