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 BEA5E7FC43 for ; Wed, 4 Mar 2015 11:17:09 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.09,686,1418079600"; d="scan'208";a="124316632" Received: from adijon-652-1-205-229.w90-56.abo.wanadoo.fr (HELO alcazar2) ([90.56.188.229]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 04 Mar 2015 11:17:06 +0100 Date: Wed, 4 Mar 2015 11:17:05 +0100 From: Maxence Guesdon To: caml-list@inria.fr Message-ID: <20150304111705.56f40bf3@alcazar2> In-Reply-To: <1425375614.6247.18.camel@e130.lan.sumadev.de> References: <20150302184846.2531e792@alcazar2> <20150302192423.11734fc7@alcazar2> <1425375614.6247.18.camel@e130.lan.sumadev.de> Organization: INRIA X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] syntax extensions with ocamlfind On Tue, 03 Mar 2015 10:40:14 +0100 Gerd Stolpmann wrote: > Am Montag, den 02.03.2015, 19:24 +0100 schrieb Maxence Guesdon: > > On Mon, 2 Mar 2015 18:07:40 +0000 > > Andreas Hauptmann wrote: > > > > > On Mon, 2 Mar 2015 18:48:46 +0100 > > > Maxence Guesdon wrote: > > > > > > > It seems that ocamlfind only supports camlp4 for preprocessors. Am I > > > > right ? Does anybody known how to achieve this ? > > > > > > Take a look at the META file of camlp5. If i remember right, it achieves > > > similar without native support inside ocamlfind. > > > > Indded, thanks. But it seems that ocamlfind can handle only one > > preprocessor, instead of building a command chaining the preprocessors. > > Chaining isn't that easy. Remember that preprocessors cannot only output > source code, but also parsed ASTs. But ASTs are normally not understood > as input by the next preprocessor in the chain. This is because "legacy" preprocessors were quite advanced. One constraint could be that preprocessor read and output text. > Also, preprocessors usually exist to process non-standard syntax. In a > chain pp1|pp2, however, pp1 will most likely not understand the > extensions understood by pp2, and instead run into a parser error. That > makes chaining a questionable concept. Indeed, but in my case, my preprocessor is just a lexer, mapping <:blabla< >> quotes to extension nodes [%blabla ]. So it can read any other syntax and output it as it is in the original file. I make this to replace a camlp4 extension. This simple preprocessor maps the quotations to the ppx world. > Note that chaining works with the new-style ppx preprocessors. This is > possible because these preprocessors are restricted to the official > syntax (which was extended to make this useful). The ppx chaining is > directly implemented in the compiler. > And that's great :) > > When I have more than one packages defining a preprocessor, I get: > > > > ocamlfind: Several packages are selected that specify preprocessors: > > package camlp4 defines `camlp4', package mypkg.syntax defines > > `./mypp' > > > [...] > > So the preprocessor machinery seems very camlp{4,5} oriented. > > Yes, it is, at least regarding the style the preprocessor is invoked. > > What is imaginable is that there is some additional preprocessor driver. > Let's call it ocamlpp. It would do the chaining for those preprocessors > that are compatible. If you call it like > > ocamlpp (command | object.cmo) ... > > it runs the preprocessors on the command line in turn, either by > executing a command or loading the object. Such a driver would fit into > the findlib framework. > > But as said, I doubt that such a driver would be very useful, as > chaining several preprocessors is normally not possible. I agree this is a corner case. Thanks for your response. - Maxence