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=1.0 required=5.0 tests=AWL,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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id CA37CBBCA for ; Thu, 28 Feb 2008 19:17:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPOIxkfRVciqgWdsb2JhbACDIY1QAQEIBQQTFoEPlCuHTw X-IronPort-AV: E=Sophos;i="4.25,421,1199660400"; d="scan'208";a="23175019" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Feb 2008 19:17:38 +0100 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 m1SIHbaD006719 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 28 Feb 2008 19:17:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPOIxkfRVciqgWdsb2JhbACDIY1QAQEIBQQTFoEPlCuHTw X-IronPort-AV: E=Sophos;i="4.25,421,1199660400"; d="scan'208";a="23175016" Received: from wf-out-1314.google.com ([209.85.200.170]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Feb 2008 19:17:37 +0100 Received: by wf-out-1314.google.com with SMTP id 26so4856949wfd.0 for ; Thu, 28 Feb 2008 10:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=A2qvzDO2vVdSy1if3ZdoxxkrSZ1yaGs1zTZ0qrBzMQ4=; b=G+COifVHSwMB3or7bSrJ+138GFdb/xp44C5Jt658oC2AlKtCsDiHrGNiGVrGi+dHQa3c5wv7+W2XwhSaR3/QtXENtkGLpq9kp2baAcTQpFItpXGUD5f7P5T2CpXyJjy9nTxG7Iaw6DBqX1k1vuWj2daGCIBVimWjbiVEFLjUy1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XR9A6kzflsnzgUiFuBh6Dyx5bfh/B1z5rrxJ2qkFOVs1vzpJJGl6wednKdj+aGoJeaaMgznTgfrH+T54hB7lTV0grWHozbzcaKougHjj4xBpcv2rMUtYf/FalEYRCXq68Vcoz7Og3AWMbu5Pv4ws6Ps8T3uphPznnz5CRLLxVFQ= Received: by 10.142.213.9 with SMTP id l9mr6479484wfg.180.1204222656076; Thu, 28 Feb 2008 10:17:36 -0800 (PST) Received: by 10.142.102.3 with HTTP; Thu, 28 Feb 2008 10:17:36 -0800 (PST) Message-ID: Date: Thu, 28 Feb 2008 13:17:36 -0500 From: "Markus Mottl" To: "Jeremy Yallop" Subject: Re: [Caml-list] Deriving + type-conv + OCaml-Templates + camlp4* = ? Cc: "David Teller" , OCaml In-Reply-To: <47C541FB.30508@ed.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1204057629.6163.50.camel@Blefuscu> <47C541FB.30508@ed.ac.uk> X-Miltered: at discorde with ID 47C6FAC1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 camlp:01 trade-offs:01 recursion:01 backtracking:01 semantics:01 recursion:01 -rectypes:01 compiler:01 ocaml:01 polymorphic:01 polymorphic:01 On Wed, Feb 27, 2008 at 5:56 AM, Jeremy Yallop wrote: > > I think that different projects have different trade-offs that are > > hard, if not impossible, to combine. > > I fear that you may be right, although (as the author of deriving) I'd > be more than happy to consider collaboration, given a concrete proposal. We'd certainly be very happy to have a general framework for deriving code from type definitions, since we (Jane Street Capital) have been using this idea very successfully in our projects. Having written two complete and fairly complex libraries of that kind, I found that the overlap between them was so small that it almost doesn't count in comparison to the total effort required. Thus I'm rather skeptical that a general purpose library for type-derived code will be possible without giving up on performance, but I'd surely like to be surprised.... > This is a little more surprising, since completeness *is* a focus of > deriving. > > If I understand you rightly, then the case you mention is actually > handled: are you referring to using deriving with a polymorphic variant > type that extends another, such as > > type a = [`A] > type ab = [a|`B] Right. > This sort of thing is certainly handled; indeed, deriving handles > considerably more complicated cases as well, e.g. involving various > sorts of recursion: Ok, I possibly misremembered something. Sorry about that. Sexplib treats this issue (inherited polymorphic variant types) by using backtracking. This has the advantage of a clear semantics concerning which type converter will be used if types overlap (always the first one left-to-right). This doesn't seem to be the case with some Deriving generators, but this may not be a big deal there. > To avoid giving the impression that deriving is absolutely complete, I > should mention that nested (i.e. irregular) types are not handled. This > is in some ways a limitation of the approach of using modules for > recursion. I don't think this limitation is significant for most > people, but I may look into adding support at some point. This is surely a very minor limitation. I can't remember the last time I encountered irregular types in real life. Sexplib seems to support them, though one has to pass the -rectypes flag to the compiler, of course. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com