From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 9FB86801CD for ; Thu, 17 Aug 2017 13:57:29 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=christoph.hoeger@celeraone.com; spf=Pass smtp.mailfrom=christoph.hoeger@celeraone.com; spf=None smtp.helo=postmaster@mail-oi0-f44.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@celeraone.com) identity=pra; client-ip=209.85.218.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="christoph.hoeger@celeraone.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of christoph.hoeger@celeraone.com designates 209.85.218.44 as permitted sender) identity=mailfrom; client-ip=209.85.218.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="christoph.hoeger@celeraone.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f44.google.com) identity=helo; client-ip=209.85.218.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="postmaster@mail-oi0-f44.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3ApyuCoRzmYw5qw+LXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0e4WIJqq85mqBkHD//Il1AaPBtqLra8cw8Pt8IneGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2TxTor3az9T8fHAnkfUow?= =?us-ascii?q?f7ytW92as8Pi8Mu7/pmbRgxJgDu7bvtWLQ6q5VHav8wSxI9jMboZyx3To3IOdf?= =?us-ascii?q?4AgStmP1uVlBH9/YGo+4J/8ilKk/Mn7c9JF6vgLIoiSrkNJzQ8Mnsp49Xrgjld?= =?us-ascii?q?QgaVri8XUn8XiQZPGwiD7Bb3UZrrmiD3sudn0S6cMIv9SrViCmfq1LtiVBK90H?= =?us-ascii?q?RPDDU+6myCz5Uo1K8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAwBahJVZfyzaVdFUCR4GDBcBAQQBA?= =?us-ascii?q?QoBAYUoB4UmmHeSUoU3DoElA1yKFwdBFgEBAQEBAQEBAQEBEgEBCQsLCCYxgjM?= =?us-ascii?q?FAR4BBYJlHQEBOBgGBzcCJBIBBQEWDAGKQoxDkRs/ix9rgiaDCAEBBYhTKggSg?= =?us-ascii?q?xaCAosTDIM9gmGgTpRCklyUVBUfgRUmB4E0d3gGhGiCFD42AYdiKkSBUwEBAQ?= X-IPAS-Result: =?us-ascii?q?A0AeAwBahJVZfyzaVdFUCR4GDBcBAQQBAQoBAYUoB4UmmHe?= =?us-ascii?q?SUoU3DoElA1yKFwdBFgEBAQEBAQEBAQEBEgEBCQsLCCYxgjMFAR4BBYJlHQEBO?= =?us-ascii?q?BgGBzcCJBIBBQEWDAGKQoxDkRs/ix9rgiaDCAEBBYhTKggSgxaCAosTDIM9gmG?= =?us-ascii?q?gTpRCklyUVBUfgRUmB4E0d3gGhGiCFD42AYdiKkSBUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,387,1498514400"; d="scan'208,217";a="234664683" Received: from mail-oi0-f44.google.com ([209.85.218.44]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 17 Aug 2017 13:57:14 +0200 Received: by mail-oi0-f44.google.com with SMTP id f11so63827734oic.0 for ; Thu, 17 Aug 2017 04:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=celeraone-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ENskVSg26wCG8jhdPQAnNL6uUX7SWOaQlUaHqcVVRjQ=; b=ywkV0A+JcWhpWqtHuiChzDOpDJ4Vgb/Isgcy018DfN5V8ucIkq7+Pcar4nDQYOixsG Og20SNU0m0MNVr85IQmIeLow97yql2lnssc8oFeOr6WW4sCVTg0XkH5aVyJrXfPQIOnn ahkFEmXx2GgEhOFFfqulJTwfOdhQNoiuZVl7d0b9rXep60gNPxOeFvNB4WIxz+MPTN1g TGLm8nQSa7Eei9U8en8EcR5K0cz1NmKvcklrQrfBlPEJ70a4aKo2wDS94IgtUknnPrag BLbuk5LFsybHInXSSdOTBKnaEuRsroYoZb7cEXJ/GgVShwf2dch/WTCb9cx45FWiupE1 CiiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ENskVSg26wCG8jhdPQAnNL6uUX7SWOaQlUaHqcVVRjQ=; b=QHFLFZPt499JpTPD8zjXvTsk7AY9BljPSozbS2CiDjZy76yHVDddEw6tp18Mas0Z9a FWDNYULzSn4QDQgPp40IjoUSAFjIyjvUlBFoKVml7FH9V/U8bLMjMHikYDs8Gmy2tyvn 64ejXzlWFoDiRXbmm3kk2vj5tO2lQm6bTl4t+fIaJ6p94GgitAo7GSWwxE2hx2O+Pg7a BHZA+zk9E+lGkHM+8McRU3HcsGtQIgkIVMwwMYO9UjSzqhQnVnwRmMvNm2o9PWx/iDBE B/NClduwEhp0OKHMMVrTnmggsZUDeFqb2tVNoH2XHhb3rPWQJ10/ktraHyaQlj28K8Xk BtDA== X-Gm-Message-State: AHYfb5h2sergxxPEu+KhQm+txQS89ulyi9AoaVGiBkBsgR2Gsvih3/tt k9TcZXbpExRNf0OAmNQj2WFtkM5T1aM5o6s= X-Received: by 10.202.220.133 with SMTP id t127mr6881076oig.242.1502971032265; Thu, 17 Aug 2017 04:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.5.68 with HTTP; Thu, 17 Aug 2017 04:57:11 -0700 (PDT) From: =?UTF-8?Q?Christoph_H=C3=B6ger?= Date: Thu, 17 Aug 2017 13:57:11 +0200 Message-ID: To: OCaml Mailing List , francois.pottier@inria.fr Content-Type: multipart/alternative; boundary="001a113d59767c79a50556f1b61d" Subject: [Caml-list] default fold for visitors --001a113d59767c79a50556f1b61d Content-Type: text/plain; charset="UTF-8" Dear all (especially Francois), I am currently porting a DSL to OCaml and wanted to use the most modern ppx approach for the typical boilerplate. One of the first things is the implementation of the free variables with the help of ppx_visitors. Naturally, the set of free variables forms a monoid, so I can comfortably use the reduce variety. But that allocates quite a lot of temporary sets, so I had a look into the fold variety. If I understand the documentation correctly, this class requires to define a build method for each variant of the datatype. I wonder if there is a way to have a "default" function, namely the identity of the result value? Consider, for example the simple lambda calculus: type expr = Abs of (string[@opaque]) * expr | App of expr * expr | Var of (string[@opaque]) [@@deriving visitors { variety = "fold" }] In that case, you'd want to define method build_Abs () x = StrSet.remove x method build_Var () = StrSet.singleton but also have to method build_App () = StrSet.union According to the manual, the visitor should be something like this: method visit_App () l r fvs0 = let fvs1 = self#visit_expr () l fvs0 in let fvs2 = self#visit_expr () l fvs1 in self#build_App () fvs1 fvs2 (* Why is this /always/ necessary ? *) I suppose this final step of building the results allows some flexibility, but in my case I could as well just yield fvs2. I wonder if it would be possible to have a default implementation like this: method build_App () _ r = r For now, I am perfectly fine with the reduce variety, but I suppose that there are some use cases where you would actually need to fold, but only some variants actually do something. Is this a reasonable idea or is there some caveat in the design of ppx_visitors that makes it impossible? thanks, Christoph --001a113d59767c79a50556f1b61d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all (especially Francois),

I am currently port= ing a DSL to OCaml and wanted to use the most modern ppx approach for the t= ypical boilerplate. One of the first things is the implementation of the fr= ee variables with the help of ppx_visitors. Naturally, the set of free vari= ables forms a monoid, so I can comfortably use the reduce variety. But that= allocates quite a lot of temporary sets, so I had a look into the fold var= iety.

If I understand the documentation correctly, this class requi= res to define a build method for each variant of the datatype. I wonder if = there is a way to have a "default" function, namely the identity = of the result value?

Consider, for example the simple lambda calcul= us:


type expr =3D Abs of (string[@opaque]) * expr | App of expr = * expr | Var of (string[@opaque]) [@@deriving visitors { variety =3D "= fold" }]

In that case, you'd want to define

method = build_Abs () x =3D StrSet.remove x
method build_Var () =3D StrSet.singl= eton

but also have to

method build_App () =3D StrSet.union
According to the manual, the visitor should be something like this:
method visit_App () l r fvs0 =3D
=C2=A0 let fvs1 =3D self#visit_exp= r () l fvs0 in
=C2=A0 let fvs2 =3D self#visit_expr () l fvs1 in
=C2= =A0 self#build_App () fvs1 fvs2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (* Why is this /always/ ne= cessary ? *)

I suppose this final step of building the results allow= s some flexibility, but in my case I could as well just yield fvs2. I wonde= r if it would be possible to have a default implementation like this:
method build_App () _ r =3D r

For now, I am perfectly fine with th= e reduce variety, but I suppose that there are some use cases where you wou= ld actually need to fold, but only some variants actually do something. Is = this a reasonable idea or is there some caveat in the design of ppx_visitor= s that makes it impossible?

thanks,

Christoph
--001a113d59767c79a50556f1b61d--