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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 40A57BC69 for ; Tue, 17 Jul 2007 11:08:26 +0200 (CEST) Received: from dorado.vub.ac.be (smtp.vub.ac.be [134.184.129.10]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6H98PvY032741 for ; Tue, 17 Jul 2007 11:08:26 +0200 Received: from exchange.etro.vub.ac.be (etro10.vub.ac.be [134.184.2.10]) by dorado.vub.ac.be (Postfix) with ESMTP id 917E748A for ; Tue, 17 Jul 2007 11:08:21 +0200 (CEST) Received: from ssel.vub.ac.be ([10.0.4.37]) by exchange.etro.vub.ac.be with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 11:08:21 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by ssel.vub.ac.be (Postfix) with ESMTP id 208DC246818E for ; Tue, 17 Jul 2007 11:08:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at ssel.vub.ac.be Received: from ssel.vub.ac.be ([127.0.0.1]) by localhost (ssel.vub.ac.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELp+4vWUWaEy for ; Tue, 17 Jul 2007 11:08:12 +0200 (CEST) Received: from [10.0.4.145] (unknown [10.0.4.145]) by ssel.vub.ac.be (Postfix) with ESMTP id 472FF246818D for ; Tue, 17 Jul 2007 11:08:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Caml-list ml From: Bruno De Fraine Subject: camlp4: question about functor-style syntax extensions Date: Tue, 17 Jul 2007 11:08:09 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jul 2007 09:08:21.0439 (UTC) FILETIME=[05D9ECF0:01C7C852] X-Miltered: at discorde with ID 469C8709.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; camlp:01 syntax:01 syntax:01 camlp:01 defines:01 struct:01 sig:01 struct:01 expr:01 expr:01 functor:01 functor:01 toplevel:01 sig:01 structurally:01 Hello, Here's a minimal syntax extension in the functor-style, which seems to be preferred style with the new camlp4. It defines a PI constant which can be used inside expressions: module Id = struct let name = "pi" and version = "3.14" end open Camlp4.Sig module Pi(Syntax : Camlp4Syntax) = struct include Syntax EXTEND Gram expr: LEVEL "simple" [[ "PI" -> <:expr< $flo:"3.14159265358979312"$ >> ]]; END end let module M = Camlp4.Register.OCamlSyntaxExtension(Id)(Pi) in () As mentioned in the documentation, an extension (such as Pi) must be functor: Camlp4Syntax -> Camlp4Syntax, and Register.OCamlSyntaxExtension requires this type. This is why I have to "include" (instead of "open") the original syntax: to produce a valid output syntax. My question is: how is this output syntax ever used? (Note that the EXTEND-statement does not make any structural changes to the syntax module, just dynamic changes as a side-effect upon functor application.) To put all my cards on the table: I believe the output syntax is never used. For example, you can sabotage one of the main grammar entries by finishing the definition of Pi with: let top_phrase : Ast.str_item option Gram.Entry.t = Obj.magic 0 And the extension keeps working all the same from the toplevel. In fact, a look at the code of OCamlSyntaxExtension in Register.ml confirms it is never used: module OCamlSyntaxExtension (Id : Sig.Id) (Maker : functor (Syn : Sig.Camlp4Syntax) -> Sig.Camlp4Syntax) = struct declare_dyn_module Id.name (fun _ -> let module M = Maker Syntax in ()); end; The output syntax M is thrown away, i.e. the syntax extension relies entirely on side-effects of the functor application. I think the type required for a syntax extension could just as well have been a functor that return an empty module: Camlp4Syntax -> sig end Why bother making this remark if you can just include the original syntax at the beginning and it works? I believe there are two important reasons. The first is didactical: the signature Camlp4Syntax -> Camlp4Syntax suggests that the syntax extension works by structurally transforming one syntax into another, while this is not what is going on. This situation makes the workings of camlp4 all the more difficult to understand for novice (and perhaps seasoned) camlp4 developers. The second reason is practical: you can easily define something in your extension that clashes with a name from Camlp4Syntax (e.g. "expr"), and then the compiler will complain if the types do not agree. You can assure you export the exact original definitions by putting "include Syntax" at the end of the extension instead of the beginning, but then you still need an "open Syntax" at the beginning to have the useful modules (like Ast, Gram, etc.) available. All of this is an annoying redundant idiom given that the output Syntax is not used. Regards, Bruno -- Bruno De Fraine Vrije Universiteit Brussel Faculty of Applied Sciences, DINF - SSEL Room 4K208, Pleinlaan 2, B-1050 Brussels tel: +32 (0)2 629 29 75 fax: +32 (0)2 629 28 70 e-mail: Bruno.De.Fraine@vub.ac.be