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 CBEC17FCCB for ; Wed, 8 Apr 2015 21:00:07 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of drupyog+caml@zoho.com) identity=pra; client-ip=74.201.84.155; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of drupyog+caml@zoho.com designates 74.201.84.155 as permitted sender) identity=mailfrom; client-ip=74.201.84.155; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="drupyog+caml@zoho.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@sender1.zohomail.com) identity=helo; client-ip=74.201.84.155; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="drupyog+caml@zoho.com"; x-sender="postmaster@sender1.zohomail.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AABgeSVVm5tUyUpcg1pcgxXCMoUvTgKBLDwQAQEBAQEBAREBAQEBAQgJCwkULoQgAQEEIw8BBQsBNAMOCxoCBRYLAgIJAwIBAgFFBgEMCAEBiBEBAwEEDAQJtUVwhGcCi10iKCWFIgEBCAIBGAMEgSGKCoUDgmiBRZF/gnKCJ4Nogi+EZ41FhBNtgkMBAQE X-IPAS-Result: A0D6AABgeSVVm5tUyUpcg1pcgxXCMoUvTgKBLDwQAQEBAQEBAREBAQEBAQgJCwkULoQgAQEEIw8BBQsBNAMOCxoCBRYLAgIJAwIBAgFFBgEMCAEBiBEBAwEEDAQJtUVwhGcCi10iKCWFIgEBCAIBGAMEgSGKCoUDgmiBRZF/gnKCJ4Nogi+EZ41FhBNtgkMBAQE X-IronPort-AV: E=Sophos;i="5.11,545,1422918000"; d="scan'208";a="108880267" Received: from sender1.zohomail.com ([74.201.84.155]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-MD5; 08 Apr 2015 21:00:06 +0200 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=Vy3RdvZ1O7AtHMi/mDiUj0N6N/cnzh1V1d6+PNLJb2+hAQRq2TSQeoMubRomCjYvCT9Wo6zckvu2 Wgh/J/mOwoh/J1B7NjsRZWVq/OGSIMuNWSoFoPj6sedF9Yv2I3bK Received: from [192.168.1.8] (did75-8-82-228-42-129.fbx.proxad.net [82.228.42.129]) by mx.zohomail.com with SMTPS id 1428519600818122.50493813467654; Wed, 8 Apr 2015 12:00:00 -0700 (PDT) Message-ID: <55257AAD.6030004@zoho.com> Date: Wed, 08 Apr 2015 20:59:57 +0200 From: Drup User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dario Teixeira , caml-list References: <2f9c74beafcf41f3ab30324fb1ece739@nleyten.com> In-Reply-To: <2f9c74beafcf41f3ab30324fb1ece739@nleyten.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] META file standards for ppx extensions I'm not fond of b). ppx_deriving et ppx_import don't follow this scheme, and that's rather understandable given the absence of runtime library. Otherwise yes. lwt, js_of_ocaml follow that and it was widely adopted for camlp4, so it shouldn't be an issue. Le 08/04/2015 20:20, Dario Teixeira a écrit : > Hi, > > I think we need to standardise the naming and structure of META > files associated with ppx extensions. Case in point: I was hoping > to start using sedlex instead of ulex, because the latter has been > deprecated for a while now and all the cool kids are switching to > the former. However, sedlex currently ships with a broken META > file that severely restricts its usefulness [1]. Therefore, in > order to avoid similar problems with other ppx extensions and to > foster some uniformity in the ecosystem, here's what I suggest: > > a) Suppose you have a ppx extension called 'foobar' that relies > on a runtime library foobar.cma (and native code counterparts, > which I'll omit from now on). The top-level declarations in > foobar's META should reference foobar.cma, but should *not* > include a ppx declaration. The ppx declaration should be > part of a 'ppx' sub-package. > > b) If the ppx extension 'foobar' does not have a runtime library, > then the top-level declarations in the META file should consist > only of generic version and description information. The actual > ppx declaration should be part of a 'ppx' sub-package, as in a). > > There is obviously an alternative approach where the ppx invocations > are located at the top-level and any potential runtime libraries > are moved into a 'lib' sub-package. I prefer the approach outlined > above, however, as it makes ppx invocations explicit and follows the > 'syntax' sub-package tradition from Camlp4's glory days. > > Thoughts or suggestions? > > Best regards, > Dario Teixeira > > [1] https://github.com/alainfrisch/sedlex/issues/22 > >