From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <whitequark@whitequark.org>
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 4B5F6800BE
	for <caml-list@sympa.inria.fr>; Fri,  6 Jan 2017 23:58:51 +0100 (CET)
Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=whitequark@whitequark.org; spf=Pass smtp.mailfrom=whitequark@whitequark.org; spf=None smtp.helo=postmaster@uruz.whitequark.org
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  whitequark@whitequark.org) identity=pra;
  client-ip=188.166.218.19;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="whitequark@whitequark.org";
  x-sender="whitequark@whitequark.org";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  whitequark@whitequark.org designates 188.166.218.19 as
  permitted sender) identity=mailfrom;
  client-ip=188.166.218.19;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="whitequark@whitequark.org";
  x-sender="whitequark@whitequark.org";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@uruz.whitequark.org) identity=helo;
  client-ip=188.166.218.19;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="whitequark@whitequark.org";
  x-sender="postmaster@uruz.whitequark.org";
  x-conformance=sidf_compatible
IronPort-PHdr: =?us-ascii?q?9a23=3ABJJ5ux+4p3MoBv9uRHKM819IXTAuvvDOBiVQ1KB9?=
 =?us-ascii?q?0e8cTK2v8tzYMVDF4r011RmSDNmdsasP0rSI++C4ACpbvsbH6ChDOLV3FDY7yu?=
 =?us-ascii?q?wu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk6nbVk9?=
 =?us-ascii?q?Dq3PF4XTl8W60fyps92WOl0QxWn1XbQnAg+/q64escgNybNlNrowxwGB9nVScu?=
 =?us-ascii?q?JdwmJzY0qUgwr9692Y/Zh58i0Wteh3pOBaVqCvYKQ5UbFBET08MChh+83qqRTa?=
 =?us-ascii?q?UAKV5VMDUmQKnwNVChLGqhbgUcGi4WPBquNh1XzCboXNRrcuVGHntv8zRQ=3D?=
 =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtGABdIHBY/xPaprxeGwEBAQMBAQEJA?=
 =?us-ascii?q?QEBFgEBAQMBAQEJAQEBgw4BAQEBAR+EbIVWlyKXL4YiAoFWRA8BAQEBAQEBAQE?=
 =?us-ascii?q?BAWIogjMEARUBBIIXAQUjDwEFQRAEBwkPAgIYDgICLCsGG4hssD6CJYogAQEIA?=
 =?us-ascii?q?gElgQuFOYRihEaDCIJeBZsVgk6OcJBkSJIJNyCBSYZhPodMgU8BAQE?=
X-IPAS-Result: =?us-ascii?q?A0AtGABdIHBY/xPaprxeGwEBAQMBAQEJAQEBFgEBAQMBAQE?=
 =?us-ascii?q?JAQEBgw4BAQEBAR+EbIVWlyKXL4YiAoFWRA8BAQEBAQEBAQEBAWIogjMEARUBB?=
 =?us-ascii?q?IIXAQUjDwEFQRAEBwkPAgIYDgICLCsGG4hssD6CJYogAQEIAgElgQuFOYRihEa?=
 =?us-ascii?q?DCIJeBZsVgk6OcJBkSJIJNyCBSYZhPodMgU8BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,326,1477954800"; 
   d="scan'208";a="253492597"
Received: from uruz.whitequark.org ([188.166.218.19])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 23:58:48 +0100
Received: by uruz.whitequark.org (Postfix, from userid 1002)
	id BE435203A9; Fri,  6 Jan 2017 17:58:45 -0500 (EST)
To: François Pottier <francois.pottier@inria.fr>
X-PHP-Originating-Script: 0:rcube.php
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 06 Jan 2017 22:58:45 +0000
From: whitequark <whitequark@whitequark.org>
Cc: caml users <caml-list@inria.fr>
In-Reply-To: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr>
References: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr>
Message-ID: <afb2edafca674707e3bace87ea47d253@whitequark.org>
X-Sender: whitequark@whitequark.org
User-Agent: Roundcube Webmail/1.2.2
Subject: Re: [Caml-list] ppx_deriving question: deferring code generation?

On 2017-01-04 13:08, François Pottier wrote:
> I am imagining that perhaps the user could write something like this:
> 
>   type foo =
>     Bar | Baz
>     [@@deriving visitors { delayed = true }
> 
>   let x : foo option ref =
>     ref None
> 
>   [@@visitors]
> 
> The effect of the flag { delayed = true } would be to store the 
> generated code
> somewhere in memory (instead of emitting right away), and the effect of 
> the
> floating attribute [@@visitors] would be to fetch that code from memory 
> and
> emit it.
> 
> To me, this seems somewhat ugly, but workable. Does ppx_deriving offer 
> a
> better approach? Does anyone have a better suggestion? Comments are
> appreciated.

ppx_deriving currently does not allow for any (non-horrible) way to do 
this.
I am OK with the approach you propose.

-- 
whitequark