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 E30407FA31 for ; Tue, 15 Jul 2014 15:59:41 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of benjamin.canou@gmail.com) identity=pra; client-ip=74.125.82.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="benjamin.canou@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of benjamin.canou@gmail.com designates 74.125.82.179 as permitted sender) identity=mailfrom; client-ip=74.125.82.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="benjamin.canou@gmail.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-we0-f179.google.com) identity=helo; client-ip=74.125.82.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="postmaster@mail-we0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4BAJMyxVNKfVKzm2dsb2JhbABZhDeCdsZAAYELFg8BAQEBAQYLCwkUKIQEAQEDARIRDwEFCAEbCxMDDAYFCw8CBSECAg8CEhEBBQEcBgEMCAIXB4gLAQMJCAWlTWqLJ4FygxCLPAoZJw1khicRAQUOgR6NSF6Cd4FMAQSWfYQbhxOLIUGEdmqBBA X-IPAS-Result: Aj4BAJMyxVNKfVKzm2dsb2JhbABZhDeCdsZAAYELFg8BAQEBAQYLCwkUKIQEAQEDARIRDwEFCAEbCxMDDAYFCw8CBSECAg8CEhEBBQEcBgEMCAIXB4gLAQMJCAWlTWqLJ4FygxCLPAoZJw1khicRAQUOgR6NSF6Cd4FMAQSWfYQbhxOLIUGEdmqBBA X-IronPort-AV: E=Sophos;i="5.01,665,1400018400"; d="scan'208";a="71452426" Received: from mail-we0-f179.google.com ([74.125.82.179]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Jul 2014 15:59:40 +0200 Received: by mail-we0-f179.google.com with SMTP id u57so3389242wes.24 for ; Tue, 15 Jul 2014 06:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NIu16ZFwNlFowtQ+ca7SkJ51EgWAU/0ngiuCxGkO3FQ=; b=pmdSR6lyFiMnLX85lEUfOeLJL/ZdeW33tsa4xnBnCJh6q6Iw6J0mZSiPdQFEsIcgWo 2ePKeZEHJBEBAllarYjt6eGyL1FC0WpxXMr0Adc3nBPtW/EcJxLIdDui95oo/16xPvIQ VOCoKT1PJlOeYeuPLiO4Y2OlUGx5PWFI4qQkbTPCLSj0LuqvcuQLnDZxLTr5AHH81clv whpw8K0SfPDtbeiilEJXn1Qz+83YIxkZJL0EWxp9E9UHK6Y0abHuD0zKL8xCysrydivK yH1W/8sxxdrIpFB6NDLTK70P7bCyTVP/Kbm8LcaG54aQX77e7CXvzkIq+AXwE5jmaIBj PBQg== X-Received: by 10.194.63.77 with SMTP id e13mr11968539wjs.104.1405432779948; Tue, 15 Jul 2014 06:59:39 -0700 (PDT) Received: from [128.93.60.57] (tridgell.inria.fr. [128.93.60.57]) by mx.google.com with ESMTPSA id eo4sm44137204wid.4.2014.07.15.06.59.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jul 2014 06:59:39 -0700 (PDT) Message-ID: <53C533CA.208@gmail.com> Date: Tue, 15 Jul 2014 15:59:38 +0200 From: Benjamin Canou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Alain Frisch , caml-list@inria.fr References: <53BFE73E.6060106@gmail.com> <53C00D35.5020703@frisch.fr> In-Reply-To: <53C00D35.5020703@frisch.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] proposal for finding, loading and composing ppx preprocessors Le 11/07/2014 18:13, Alain Frisch a écrit : > Hi Benjamin, > > This topic of how to specify which ppx processors to run, and avoiding > multiple processes, is indeed still largely opened. > > I don't see what's the benefit of restricting the processors to > subtrees. It's easy enough for each processor to traverse extension > nodes it doesn't support (this is the behavior of the default mapper). > And I don't think it's a good idea to introduce a composition model > different from the successive application of different processors on > the entire tree. I.e. function composition, which is quite well > understood and easy to reason about. In particular, you only need to > understand the behavior of each processor to predict what the > composition will do, not exactly how each processor is implemented > (and which state it carries across the tree, internally). My belief is that there is room for a less ambitious, plug-in based (statically or dynamically linked) annotation mechanism, on top of PPX. For instance, if we consider the current use of camlp4, we can assume that most ppxs will probably just define some annotation on some specific kind of AST node in order to rewrite them and / or insert auxiliary code, without carrying so much state. Having a common mechanism for registering such common simple tasks and assigning to names to them could be useful, without breaking the model. In practice, an annotation would simply be declared as an OCaml module calling predefined specific registration functions. Such a module, linked with a predefined main module would produce a stand alone ppx binary processing only this annotation. However, it gives the possibility to compose annotations more finely, without changing the semantics. As I mentioned previously, It could limit the number of tree rewrites, but it could have other advantages such as detecting annotation name clashes. We launched this thread because we thought that such a mechanism has more chances to be adopted if previously discussed and understood by build systems, but perhaps the best solution is that we propose such a ppx helper and then wait and see. > > With ocamlfind 1.5, requiring a package when compiling a file adds the > required -ppx flags in addition to the -I flags. If we want to avoid > multiple process, one could create a meta ppx driver which dynamically > loads and runs other drivers (specified as .cmxs files). To be able > to use such as meta driver from ocamlfind, ocamlfind needs to know > about how to build each ppx processor (i.e. which libraries should be > invoked). Dynamic linking might not be the best solution, though: it > is not available on all platforms, and it requires all libraries on > which ppx processor depend to provide a corresponding .cmxs. The > alternative is to have ocamlfind link a specific meta driver > statically (using its knowledge of package dependencies) for each > actual combination of ppx to be used, relying on an internal cache to > avoid linking the same driver repeatedly, of course. The next step is > to create not ppx drivers (that incorporate multiple precessors), but > compiler drivers (to avoid completely extra process creations and > marshaling of the AST). If this is encapsulated in ocamlfind (or a > similar tool), this can still be used by any build system which > currently relies on ocamlfind. > > Specifying ppx requirements in the source code is a different topic. > It might be a good direction, but then I don't see why this should be > restricted to ppx requirements and not -I flags. It would seem logical > to specify package requirements, which would add both -I and -ppx > flags (and maybe more). I agree on this. Annotations give us the possibility to make OCaml files more self content and build-system independent. I though see a distinction between compiler directed pragmas and build-system directed ones. > > Actually, it would have been more important to specify package > requirements for Camlp4 processors, since this knowledge might be > required by tools that are not under the control of your build system, > such as your editor/IDE (to load the corresponding syntactic support). > Since the concrete syntax doesn't change anymore with ppx processors, > it seems less critical to specify them in the source code (I'd say, > not more and not less than general package requirement). Well, one of the use cases of extension nodes is to integrate external notations into literals such as [%json{| ... |}]. I believe IDEs could still use a little help to know how to format these, instead of showing plain OCaml strings. > > > -- Alain > Benjamin.