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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8BA4B7FA31 for ; Tue, 15 Jul 2014 17:56:29 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBACtOxVPB/BfTnGdsb2JhbABZg2BXgna+f4dDAYEmDwEBAQEBCAsJCRQohAMBAQQBIxVABgsLGAICBRYLAgIJAwIBAgFFBgEMCAEBiDYMCbF2mB8TBIEsjiaCd4FMAQSWfYQbhxOQWGo X-IPAS-Result: AiYBACtOxVPB/BfTnGdsb2JhbABZg2BXgna+f4dDAYEmDwEBAQEBCAsJCRQohAMBAQQBIxVABgsLGAICBRYLAgIJAwIBAgFFBgEMCAEBiDYMCbF2mB8TBIEsjiaCd4FMAQSWfYQbhxOQWGo X-IronPort-AV: E=Sophos;i="5.01,666,1400018400"; d="scan'208";a="85275597" Received: from msa02.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.211]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jul 2014 17:56:29 +0200 Received: from [192.168.1.133] ([92.151.54.109]) by mwinf5d59 with ME id SfwU1o00B2MNqdG03fwUfL; Tue, 15 Jul 2014 17:56:28 +0200 X-ME-Helo: [192.168.1.133] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Tue, 15 Jul 2014 17:56:28 +0200 X-ME-IP: 92.151.54.109 Message-ID: <53C54F32.6000201@frisch.fr> Date: Tue, 15 Jul 2014 17:56:34 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Canou , caml-list@inria.fr References: <53BFE73E.6060106@gmail.com> <53C00D35.5020703@frisch.fr> <53C533CA.208@gmail.com> In-Reply-To: <53C533CA.208@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] proposal for finding, loading and composing ppx preprocessors On 07/15/2014 03:59 PM, Benjamin Canou wrote: > 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. The registration mechanism exists: a ppx processor is supposed to call Ast_mapper.register. By default, this runs directly the main program to support for ppx protocol for this single processor, but you can very well override the behavior of Ast_mapper.register by calling Ast_mapper.register_function first. You can look at https://github.com/alainfrisch/ppx_drivers for an experiment of creating such a driver. But this notion of registration is quite independent on how multiple processors interact. I'm yet to be convinced that a composition mode more fine-grained that function composition is worth the extra mental overhead. It would also be necessary to decide between top-down and bottom-up rewriting, none of them being the best pick for all processors. Typically, a macro expander would want other processors to apply to the result of macro expansions (i.e. top-down rewriting style), while a type-conv-like processor might prefer a bottom-up rewriting (so that the macro expander can run first on type declarations before it takes control). Concerning the notion of state in ppx processors, I've written the following ppx processors: - sedlex (a lexer generator): it needs to remember about all lexer definitions in the current unit to be able to generate some global function definitions (shared by various lexers) (for instance, we don't want to generate definitions used only by code that would be excluded by a conditional compilation processor) - ppx_metaquot: some extension nodes with very short names %e, %t, %p are recognized only in the context of an enclosing extension node such as %expr ( https://github.com/alainfrisch/ppx_tools/blob/master/ppx_metaquot.ml ) I expect most other ppx processors to be slightly more complex than purely local transformations, which makes it even more difficult to reason on local composition (and "purely local" term rewriting systems are already hard to reason about their composition). > 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. Indeed, although I think this is going to be a rather rare use of extension points / quoted strings. -- Alain