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 0A58F7FCCB for ; Thu, 9 Apr 2015 12:07:54 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=pra; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=mailfrom; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay3-d.mail.gandi.net) identity=helo; client-ip=217.70.183.195; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="postmaster@relay3-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgAQBkTiZVm8O3RtlchDuDEMkGAoE5PBABAQEBAQEBEQEBAQEBBgsLCRQuhCABAQMBIxVGCwQHGgImAgJXIYgaDLYllm+BIYoKhQMWglKBRQWvaAKEEoIyfwEBAQ X-IPAS-Result: A0CgAQBkTiZVm8O3RtlchDuDEMkGAoE5PBABAQEBAQEBEQEBAQEBBgsLCRQuhCABAQMBIxVGCwQHGgImAgJXIYgaDLYllm+BIYoKhQMWglKBRQWvaAKEEoIyfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,549,1422918000"; d="scan'208";a="108952414" Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 09 Apr 2015 12:07:53 +0200 Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 42AE5A80C7 for ; Thu, 9 Apr 2015 12:07:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id VezDkQANYY9S for ; Thu, 9 Apr 2015 12:07:51 +0200 (CEST) X-Originating-IP: 10.58.1.142 Received: from webmail.gandi.net (unknown [10.58.1.142]) (Authenticated sender: dario.teixeira@nleyten.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id D3E60A80D3 for ; Thu, 9 Apr 2015 12:07:51 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 09 Apr 2015 11:07:51 +0100 From: Dario Teixeira To: caml-list@inria.fr In-Reply-To: <292F5F40C05A4B9BBEB96266F05F6FEB@erratique.ch> References: <2f9c74beafcf41f3ab30324fb1ece739@nleyten.com> <55257AAD.6030004@zoho.com> <5297cdaceccd6db2a60700bf686ccfb7@nleyten.com> <292F5F40C05A4B9BBEB96266F05F6FEB@erratique.ch> Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/0.9.5 Subject: Re: [Caml-list] META file standards for ppx extensions Hi, > It seems to me that Dario's scheme, that is always have PKG.ppx, is > more forward looking. We could perfectly imagine that a library in > the future will implement its functionality using another mechanism > (for example in a non-ugly way, using a macro system). Yes, and in the meantime I thought of another reason why the original scheme (runtime -- if any -- at the META top-level and ppx as a 'ppx' sub-package) is superior to the alternative (ppx at the top-level and runtime as 'lib' sub-package): there are libraries where the use of the syntax/ppx extension is just a nice bonus (LWT, PG'OCaml). In these cases, the original scheme is the only one that makes sense. Though there are of course extensions without a runtime where the alternative scheme would be more sensible, we then run into the consistency argument: it's preferable to bend one side to the other than to have a hodgepodge of schemes. And below you'll find additional reasons why the original scheme wins decisively. > We can imagine current packages that are using camlp4 providing > both a legacy PKG.camlp4 and a PKG.ppx package. Agreed. Case in point: LWT. I don't know when the Ocsigen team plans to eliminate the LWT Camlp4 syntax extension, but I suspect that for some time both the Camlp4 and ppx extensions will ship with LWT. The former can and should remain accessible via the lwt.syntax sub-package, whereas the latter is available via lwt.ppx. Btw, currently legacy Camlp4 syntax extensions are available as a PKG.syntax sub-package (not PKG.camlp4), and I see no compelling reason to change this. > It also makes it more clear in the build system specification > what crap pre-processing technology is being pulled in. Well, apart from the inflammatory use of 'crap', I fully agree! Best regards, Dario Teixeira