From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id CE71DBBC1 for ; Thu, 13 Mar 2008 18:09:04 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQDAE782EfRVcitkmdsb2JhbACDJI1PAQEBAQcEBAkKFpBGhnw X-IronPort-AV: E=Sophos;i="4.25,495,1199660400"; d="scan'208";a="23734086" Received: from wf-out-1314.google.com ([209.85.200.173]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Mar 2008 18:09:03 +0100 Received: by wf-out-1314.google.com with SMTP id 25so3477807wfa.15 for ; Thu, 13 Mar 2008 10:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=m27pqodI41iI7FLGa/SQR+8HS4eCB4VUyzK+lLzA4mo=; b=ExfAjtaq3ad462pQd6stTt4E5cF/0Bs28gswbtwFBbKhfVINIVDk0hItKMwamfrgVjLAkH9vooYyenlRvBQuI8v7oShmeB9qrbOoQOmNKAtpJ322wIWArH2AR9WkW5cXHVtqAJYYa/uoUg5OPManvWmwmbyffA7kZ5kbpEcTjxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iLpLHORMHwap5X2eVTClZdqF7txrooqVSzQTZ3u805YW2ETfWPEM++sWvyBGcKS/5TQ4DsuZAZVHKDE7nLU/zUpE2d6jN+wJ7skKsqWjkjGt/IyNv42xAFSS+FNTRTMXIM/F8Y3o7iUpyZk/mvJVxh94xjUcWDgRc3SQzPLd8Yc= Received: by 10.142.77.11 with SMTP id z11mr4424594wfa.98.1205428132297; Thu, 13 Mar 2008 10:08:52 -0700 (PDT) Received: by 10.142.139.13 with HTTP; Thu, 13 Mar 2008 10:08:52 -0700 (PDT) Message-ID: <527cf6bc0803131008y151941a3ka3b9e50721ba3229@mail.gmail.com> Date: Thu, 13 Mar 2008 18:08:52 +0100 From: "blue storm" To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OSR: META files for packages containing syntax extensions In-Reply-To: <1205422246.31340.1.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <98095.73991.qm@web54601.mail.re2.yahoo.com> <20080313150549.GA15068@takhisis.invalid> <1205422246.31340.1.camel@flake.lan.gerd-stolpmann.de> X-Spam: no; 0.00; syntax:01 camlp:01 camlp:01 denotes:01 parser:01 denotes:01 cmo:01 parser:01 cmo:01 parsers:01 parsers:01 syntax:01 ocaml:01 ocaml:01 ocamlfind:01 > Topic for discussion: for the sake of standardisation, it would be > nice if all packages of this type were to share a common prefix. > The most obvious candidate is "pa_". Though this can be refined later, i think we could do something a bit more elaborate there. I have not used camlp4 pre-3.10 (camlp5 these days), but if i understood correctly, prefixes were used to describe the internal machinery of the extension : pa_ denotes a parser extension, while pr_ denotes a printer extension. I do not know of any other prefix. With the new camlp4, those suffixes are not required, but they were kept in order to ease the transition (i'd assume pa_r.cmo actually refers to Camlp4Parser/Camlp4OCamlRevisedParser.cmo). This is a good idea imho, but i think that if we stick to that convention (describing the actual effect of an extension in his name) we should adopt a naming convention a bit more powerful, to reflect the actual abilities of camlp4 : for example, we can have AST filters, wich are neither parsers nor printers. Here would be a draft suggestion concerning this naming scheme : - pa_ for parsers - pr_ for printers - pf_ for filters - p_ in uncertain cases Some extensions use eg. both a parser and a filter; i guess they'd need to chose the most meaningful prefix (are they primarily intended to modify the existing syntax, or change a behavior ?). There are some code that can be described as a "syntax extension", but that does not use any of the camlp4 parser/printer/filter tools. The 'extensions' using the library type-conv ( http://www.ocaml.info/home/ocaml_sources.html#type-conv ), for example, use a specific registration mechanism. I guess the p_ prefix would be appropriate for those corner cases. I think it is important to keep a camlp5 compatibility (even if i'm not sure ocamlfind support camlp5 yet); the re-use of the standard prefixes provide this. > Another common occurrence is for the syntax extension to rely on a runtime > module or library included with the package. Another common case is when the syntax extension rely on a preprocessor-time module or library (eg. type-conv). It could be helpful to add a description of that possibility. Is there a way to specify a dependency on a specific preprocessor (between camlp4o and camlp4r, for example ?). Most extension actually won't work with both syntaxes (classical and revised), and it could be helpful to make it apparent in the package description (although most of the time an horrible preprocessor-runtime error will happen). More generally, i'm concerned with the possible incompatibilities between syntax extensions (however, this may be a bit off-topic). Thanks for that very useful proposal.