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=HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 040E6BC37 for ; Sat, 3 Oct 2009 14:16:28 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAOfcxkpZELGa/2dsb2JhbACBUVIxjyLAUYQsBIFS X-IronPort-AV: E=Sophos;i="4.44,499,1249250400"; d="scan'208,217";a="34104102" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 03 Oct 2009 14:16:27 +0200 Received: (qmail 15024 invoked by uid 634); 3 Oct 2009 12:16:26 -0000 Received: from Unknown (HELO [10.14.128.204]) (217.39.7.152) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Sat, 03 Oct 2009 13:16:25 +0100 Subject: Re: [Caml-list] Generation of Java code from OCaml Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-2--760406885 From: Anil Madhavapeddy In-Reply-To: <4ABB63ED.1000402@ens-lyon.org> Date: Sat, 3 Oct 2009 13:16:23 +0100 Cc: blue storm , caml-list@yquem.inria.fr Message-Id: <205DBD56-053A-48B6-B37F-230FB49B7499@recoil.org> References: <46ACB6F9-FFAE-4C9C-9E46-21CA2E93434C@mykola.org> <20090923195713.GA12236@annexia.org> <001a01ca3ced$8ef58050$ace080f0$@metastack.com> <527cf6bc0909240245g11ce241cr16ac482003bb25f2@mail.gmail.com> <4ABB5597.9010805@ens-lyon.org> <527cf6bc0909240502p1292ca1fs5890d3efeac49531@mail.gmail.com> <4ABB63ED.1000402@ens-lyon.org> To: Martin Jambon X-Mailer: Apple Mail (2.1076) X-Virus-Checked: Checked by ClamAV on dark.recoil.org X-Spam: no; 0.00; ocaml:01 anil:01 anil:01 syntax:01 syntax:01 sexp:01 sexp:01 foo:01 hashtbl:01 variants:01 foo:01 hashtbl:01 variants:01 char:01 char:01 --Apple-Mail-2--760406885 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 24 Sep 2009, at 13:19, Martin Jambon wrote: > > Oh yes, there's type-conv too. I don't know the pros and cons of > using either > type-conv or deriving. If anyone knows, a brief comparison would be > helpful. > The nice thing about using type-conv is that syntax extensions can be composed quite easily, as long as the generators themselves don't depend too much on custom type syntax (e.g. when using sexplib, don't use the special sexp_option/sexp_opaque types). I've ported your json-static extension over to type-conv so that we can use a combination of json/sexp and the (still in development) ORM extension side-by-side with a single type declaration, e.g. type t = { foo: string; bar: int } with orm (debug: all), json ... which generates both persistence functions and the json functions from the single type. Right now it's fairly awkward to do this with json-static and the 'predefined' keyword as it requires duplicating types. The ported version of json-static to type-conv is available at: http://github.com/avsm/caml-type-conv-json/ The only thing I haven't quite worked out yet is the quotation to pattern-match type applications to detect things like "(string, unit) Hashtbl.t" the way the current json-static does via the grammar extension. Most other types like char, int32/64, unit, poly variants, etc should all work. There's a simple testcase in check_tc.ml in the same repository. -anil --Apple-Mail-2--760406885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Oh yes, there's = type-conv too.  I don't know the pros and cons of using = either
type-conv or deriving.  If anyone knows, a brief = comparison would be = helpful.


The nice thing about = using type-conv is that syntax extensions can be composed quite easily, = as long as the generators themselves don't depend too much on custom = type syntax (e.g. when using sexplib, don't use the special = sexp_option/sexp_opaque types).

I've ported = your json-static extension over to type-conv so that we can use a = combination of json/sexp and the (still in development) ORM extension = side-by-side with a single type declaration, = e.g.

type t =3D {
  foo: = string;
  bar: int
} with orm (debug: = all), json

... which generates both persistence = functions and the json functions from the single type.  Right now = it's fairly awkward to do this with json-static and the 'predefined' = keyword as it requires duplicating types.

The = ported version of json-static to type-conv is available at:

The only thing I = haven't quite worked out yet is the quotation to pattern-match type = applications to detect things like "(string, unit) Hashtbl.t" the way = the current json-static does via the grammar extension.  Most other = types like char, int32/64, unit, poly variants, etc should all work. =  There's a simple testcase in check_tc.ml in the same = repository.

-anil
= --Apple-Mail-2--760406885--