[Caml-list] [ANN] ocamltarzan 0.1

4 views
Skip to first unread message

Yoann Padioleau

unread,
Apr 16, 2009, 2:16:38 PM4/16/09
to caml...@inria.fr

Hi List,

This is the first release of ocamltarzan, a small fork of
Jane Street sexplib that some people may found more convenient
to use.

http://aryx.kicks-ass.org/~pad/ocaml/ocamltarzan-0.1.tgz


Motivations:
--------------------

Sexplib and binprot by Jane Street are attractive, but they rely on
camlp4. I don't like camlp4. I like the metaprogramming facility it
offers but it has many disadvantages. So I've found a in-the-middle
solution where I use camlp4 to generate code (via the small script
ocamltarzan.ml), save the generated code in a file (e.g
test/foo_sexp.ml), which allows then to completely remove the
dependency to camlp4. Once the code has been generated, all
dependencies to camlp4 can be removed. If tomorrow an incompatible new
version of camlp4 arrives (e.g. camlp6 ...), your code will _still_
work, because it does not rely on the new behavior of this camlp4.
It's just regular plain good ocaml code.


Example of use:
---------------

Given a file 'foo.ml' containing a type 't' which you would like to have
'sexp_of_t' and 't_of_sexp' functions, as well as 'sexp_of_tlist' and
'tlist_of_sexp', just add a comment annotation after the types as in:

type t = A | B
(* with sexp *)
type tlist = t list
(* with sexp *)

Then use my ocamltarzan (from its source directory) on this file

$ ./ocamltarzan tests/foo.ml > tests/foo_sexp.ml

The file foo_sexp.ml should now contain the 'xxx_of_sexp' and
'sexp_of_xxx' functions.

To use the new services offered by those functions, you can
write a use_foo.ml file such as:

let x = [Foo.A;Foo.A;Foo.B;Foo.A] in
let sexp = Foo_sexp.sexp_of_tlist x in
let s = Sexp.to_string_hum sexp (* 'hum' mean human readable *) in
print_string (s ^ "\n");

let chan = open_out "out.sexp" in
output_string chan s;
close_out chan;

let sexp2 = Sexp.load_sexp "out.sexp" in
let x2 = Foo_sexp.tlist_of_sexp sexp2 in
assert (x = x2);
()

This should lead to this output:
(A A B A)

Note that once foo_sexp.ml has been generated, the only thing
you really need to compile your code is the lib-sexp/ directory,
which as you can see is a plain regular good ocaml library,
with no camlp4 stuff involved.


Pro and cons of tarzan vs jane:
-------------------------------

pro:
- less camlp4
- less complicated to build
- arguably less complicated to use, e.g. no need for the Type_conv_path stuff
- better control on the code generation as can easily customize
later the generated code, for instance
to not display certain things in sexp (like the cocci_tag, position, etc)
- can provide a path for handling different version, an evolutionnary format
- easier to debug when there is a problem ...

cons:
- have to regenerate when change code
- no Type_conv_path but have to do things manually with some module aliases
- fragile if change order in .ml ?

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Romain Beauxis

unread,
Apr 16, 2009, 3:15:30 PM4/16/09
to caml...@yquem.inria.fr
Hi !

Le Thursday 16 April 2009 14:15:40 Yoann Padioleau, vous avez écrit :
> Sexplib and binprot by Jane Street are attractive, but they rely on
> camlp4. I don't like camlp4. I like the metaprogramming facility it
> offers but it has many disadvantages. So I've found a in-the-middle
> solution where I use camlp4 to generate code (via the small script
> ocamltarzan.ml), save the generated code in a file (e.g
> test/foo_sexp.ml), which allows then to completely remove the
> dependency to camlp4. Once the code has been generated, all
> dependencies to camlp4 can be removed. If tomorrow an incompatible new

> version of camlp4 arrives (e.g. camlp6 ...), your code will still


> work, because it does not rely on the new behavior of this camlp4.
> It's just regular plain good ocaml code.

Shouldn't this just be a software/script independant from sexplib ?

On the one hand, such a technique could be useful for other code using other
camlp4 extensions, and on the other hand, this would avoid yet another fork...


Romain

Yoann Padioleau

unread,
Apr 16, 2009, 3:28:58 PM4/16/09
to Romain Beauxis, caml...@yquem.inria.fr
Romain Beauxis <to...@rastageeks.org> writes:

> Hi !
>
> Le Thursday 16 April 2009 14:15:40 Yoann Padioleau, vous avez écrit :
>> Sexplib and binprot by Jane Street are attractive, but they rely on
>> camlp4. I don't like camlp4. I like the metaprogramming facility it
>> offers but it has many disadvantages. So I've found a in-the-middle
>> solution where I use camlp4 to generate code (via the small script
>> ocamltarzan.ml), save the generated code in a file (e.g
>> test/foo_sexp.ml), which allows then to completely remove the
>> dependency to camlp4. Once the code has been generated, all
>> dependencies to camlp4 can be removed. If tomorrow an incompatible new
>> version of camlp4 arrives (e.g. camlp6 ...), your code will still
>> work, because it does not rely on the new behavior of this camlp4.
>> It's just regular plain good ocaml code.
>
> Shouldn't this just be a software/script independant from sexplib ?

It should, but the goal is to make it easier to use sexplib, and I've
found sexplib as it is right now a little bit complex to compile
(it requires ocamlfind, it requires type-conv, etc) by
default and too much tied to camlp4, hence the fork.

>
> On the one hand, such a technique could be useful for other code using other
> camlp4 extensions,

It's useful only for boilerplate related camlp4 extensions, and
except sexplib/binprot I don't know other such extensions.

> and on the other hand, this would avoid yet another fork...

sexplib has already been forked ?

Reply all
Reply to author
Forward
0 new messages