From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA29719; Tue, 9 Oct 2001 19:10:14 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA29708 for ; Tue, 9 Oct 2001 19:10:14 +0200 (MET DST) Received: from verdot.inria.fr (verdot.inria.fr [128.93.11.7]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f99HAD919382 for ; Tue, 9 Oct 2001 19:10:13 +0200 (MET DST) Received: (from ddr@localhost) by verdot.inria.fr (8.9.3/8.9.3) id TAA17055 for caml-list@inria.fr; Tue, 9 Oct 2001 19:10:13 +0200 Date: Tue, 9 Oct 2001 19:10:13 +0200 From: Daniel de Rauglaudre To: Caml Subject: Re: [Caml-list] Functors, inlining and Camlp4 Message-ID: <20011009191013.B5072@verdot.inria.fr> References: <0110091754320I.05684@beige> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0110091754320I.05684@beige>; from barnier@recherche.enac.fr on Tue, Oct 09, 2001 at 05:54:32PM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi, > In one of his answer, Xavier suggested to "manually" inline critical > code, which, I guess, means to withdraw the functors and > duplicate/specialize the module code. But I'm quite reluctant to > mess it up this way. I hardly know anything about Camlp4, but I was > wondering if it would be possible to automate this tedious task by > preprocessing the sources 1/ First answer... Mmmm... Seen like that, I don't think that Camlp4 can help. Inlining supposes to know what a definition of a variable (or a function) is, what is not supposed to be the job of a syntactic preprocessor. For it, when you write: let x = y + 1 it is interpreted (in Camlp4) as "the specific construction 'let' which has its specific syntax". That's all. The fact that "let" corresponds to a binding is semantics, not syntax. In particular, such an imaginary Camlp4 inlining could not be applied between two compilation units (i.e. between two files). If you write "Foo.xxx" in file bar.ml, Camlp4 just ignores what this "xxx" is and where Foo comes from. Well, you could imagine to do some semantics just inside a file, but I am not sure that it would be Camlp4 politically correct. 2/ Second answer... In general, in Camlp4, syntax extensions are "meta" relative to the program. To inline x, a correct usage is not to write: let x = y + 1 and hope that "x" could be inlined, but rather write a file defining x as a macro for y. This file should be separately compiled and the resulting cmo file given as parameter to Camlp4 command line. An improvement could be to add a syntax extension to do macros in general. I implemented that some time ago (but it is not distributed). If people ask for it, I can add it in the next version of Camlp4/OCaml. With this syntax extension you can write: DEFMACRO x = y + 1 and every x is inlined into "y + 1" in the current file; notice that in this case, there is no definition of x; the DEFMACRO is a directive to the preprocessor. (in this system, macros can have parameters) -- Daniel de RAUGLAUDRE daniel.de_rauglaudre@inria.fr http://cristal.inria.fr/~ddr/ ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr