From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 1E03F800B6 for ; Wed, 4 Jan 2017 14:53:14 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=christoph.hoeger@tu-berlin.de; spf=None smtp.mailfrom=christoph.hoeger@tu-berlin.de; spf=None smtp.helo=postmaster@mail.tu-berlin.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A+TkFgxRzAeW2ysY35UrGY/Q3Edpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa64YhGN2/xhgRfzUJnB7Loc0qyN4vymADFLvMvJ8ChbNscTB1ld0Y?= =?us-ascii?q?RetjdjKfDGIHWzFOTtYS0+EZYKf35e1Fb/D3JoHt3jbUbZuHy44G1aMBz+MQ1o?= =?us-ascii?q?Ora9QdaK3Iyfntq/8JzLYghOmCH1IfYrdE33/k3tsZw4m4JkpaEw0SzxpWdUeu?= =?us-ascii?q?lMjTdmP1uVlBH9/YGo+4J/8ilKk/Mn7c9JF6vgKeBwRrVdCHw7KG0v/4W/vhDG?= =?us-ascii?q?SU6L52AAemQQiBtBRQbfukLURJD05wD6rOtmxC6CPfrW0785Q3z25KdxSQT0jz?= =?us-ascii?q?8HcT4+/W7akORskedRrQilpho5z4OCM9LdD+Z3Yq6IJYBSfmFGRMsEEnUZWo4?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAAD6/GxYhyEHlYJeFgYBAQQBAQoBA?= =?us-ascii?q?RcBAQQBAQoBAYMNAQEBAQF+L10BohyVIoIIKoV4AoFQQBMBAQEBAQEBAQEBARI?= =?us-ascii?q?BAQEKCwkKHTCCMwQBFQEEghcGI2YLQgICVwYBDAYCAQGIbAQKrxaCJYozAQsXD?= =?us-ascii?q?4hHCIFRgQaHEgsugl4FmwmDZYF+c40yh1mGOUiReCEBgg6DeoFqcYZjgU8BAQE?= X-IPAS-Result: =?us-ascii?q?A0AkAAD6/GxYhyEHlYJeFgYBAQQBAQoBARcBAQQBAQoBAYM?= =?us-ascii?q?NAQEBAQF+L10BohyVIoIIKoV4AoFQQBMBAQEBAQEBAQEBARIBAQEKCwkKHTCCM?= =?us-ascii?q?wQBFQEEghcGI2YLQgICVwYBDAYCAQGIbAQKrxaCJYozAQsXD4hHCIFRgQaHEgs?= =?us-ascii?q?ugl4FmwmDZYF+c40yh1mGOUiReCEBgg6DeoFqcYZjgU8BAQE?= X-IronPort-AV: E=Sophos;i="5.33,459,1477954800"; d="asc'?scan'208";a="252836864" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 14:53:13 +0100 X-tubIT-Incoming-IP: 91.66.22.179 Received: from ip5b4216b3.dynamic.kabel-deutschland.de ([91.66.22.179] helo=[192.168.178.42]) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-5) with esmtpa id 1cOm07-0005IX-7q; Wed, 04 Jan 2017 14:53:12 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Pottier?= , caml users References: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr> From: =?UTF-8?Q?Christoph_H=c3=b6ger?= Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: Date: Wed, 4 Jan 2017 14:53:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l5OvO3W2VvuFa9bV8dckwcSdjpf0nfhSr" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.4.134816 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [Caml-list] ppx_deriving question: deferring code generation? This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l5OvO3W2VvuFa9bV8dckwcSdjpf0nfhSr Content-Type: multipart/mixed; boundary="s3G57FunUoWcJhsXW14U9sLE0kNgraGm2"; protected-headers="v1" From: =?UTF-8?Q?Christoph_H=c3=b6ger?= To: =?UTF-8?Q?Fran=c3=a7ois_Pottier?= , caml users Message-ID: Subject: Re: [Caml-list] ppx_deriving question: deferring code generation? References: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr> In-Reply-To: <9576980c-9aad-4af2-e512-dc9c42743cf2@inria.fr> --s3G57FunUoWcJhsXW14U9sLE0kNgraGm2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just out of curiosity, what does "vistors" do? If it resembles the usual Visitor Pattern you might find my ppx_deriving_morphism useful: https://github.com/choeger/ppx_deriving_morphism/ (either as a starting point or inspiration or as something to obsolete). Am 04.01.2017 um 14:08 schrieb Fran=C3=A7ois Pottier: >=20 > Hello all, >=20 > I am currently in the process of writing a ppx_deriving plugin, called > "visitors". Overall, this has been a pleasant experience; a few hundred > lines > of code have been sufficient to obtain nontrivial results. >=20 > In normal use, the user writes something like this: >=20 > type foo =3D > Bar | Baz > [@@deriving visitors] >=20 > and some generated code is inserted just after the definition of the > type foo. >=20 > However, I have reached a situation where the generated code cannot be > placed > just after the type definition. That is, I need to allow user-written > code to > appear after the type definition and before the generated code. >=20 > For instance, this user-written code could be a declaration of a global > variable "x", whose type is "foo ref", and which the generated code > uses. The > declaration of "x" must appear after the definition of the type "foo", > because > the type of "x" mentions "foo". And the declaration of "x" must appear > before > the generated code, because the generated code (intentionally) refers to > "x". >=20 > I am imagining that perhaps the user could write something like this: >=20 > type foo =3D > Bar | Baz > [@@deriving visitors { delayed =3D true } >=20 > let x : foo option ref =3D > ref None >=20 > [@@visitors] >=20 > The effect of the flag { delayed =3D true } would be to store the > generated code > somewhere in memory (instead of emitting right away), and the effect of t= he > floating attribute [@@visitors] would be to fetch that code from memory a= nd > emit it. >=20 > To me, this seems somewhat ugly, but workable. Does ppx_deriving offer a > better approach? Does anyone have a better suggestion? Comments are > appreciated. >=20 > Best regards, >=20 > --=20 > Fran=C3=A7ois Pottier > francois.pottier@inria.fr > http://gallium.inria.fr/~fpottier/ >=20 --=20 Christoph H=C3=B6ger Technische Universit=C3=A4t Berlin Fakult=C3=A4t IV - Elektrotechnik und Informatik =C3=9Cbersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de --s3G57FunUoWcJhsXW14U9sLE0kNgraGm2-- --l5OvO3W2VvuFa9bV8dckwcSdjpf0nfhSr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlhs/kcACgkQhMBO4cVSGS9cWQCdEmVTH4/dhQ97PKVVVANvqQRm NfIAn0UkVFofrQzVqNIxxWRTvnpjrnnx =5Gxf -----END PGP SIGNATURE----- --l5OvO3W2VvuFa9bV8dckwcSdjpf0nfhSr--