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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 2359F7ED45 for ; Sat, 23 Jun 2012 11:43:06 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMBACSP5U/RVda2kGdsb2JhbAArGg61UggiAQEBAQkJDQcUBCOCGAEBAQQSAhMZARsdAQMMBgULDS4hAQERAQUBHAYTCBqHWgEDCwspmngJA4wjgnGEZgoZJw1XiHEBBQyKQWOGAgOVLIESiXCDIj6DRTs X-IronPort-AV: E=Sophos;i="4.77,462,1336341600"; d="scan'208";a="164130613" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Jun 2012 11:43:05 +0200 Received: by obbun3 with SMTP id un3so5879977obb.27 for ; Sat, 23 Jun 2012 02:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CjfyfNL7tObSpvHbZT5zy59BRk0dKfWTrlZ0UKBuymI=; b=zQf8eKN8n9npC6atxaaZT+fVCWb98KC/ezdD5I/EXrC3zJXbtACLT5tZQGTyaTq4A6 fXF9prRr49XqUzKsr8xU03Ee8POK9uQFE9xVoabRRR/LDD7E0RPOIhiRorDI1TsMOY/q iCftXWiOW5RsZxxG2z83kd6ZwPXEhbBMHe0oBgHF3KY9jR7a1yH3SY+Jpl2T1GOcX7gn DMWQkMi/PUu8pj3uFd28wcqq5JzPzURjKMCoRGAyCqZZaDp0iowbOcV80h+hwy5H5SHP NTolY66Q9J6f20kMJEVMY2qsMgvbsmn4K0GhnxZimms+1P7onky3fOUmeL1HW7popIjH VkBA== Received: by 10.50.187.200 with SMTP id fu8mr3871859igc.6.1340444583847; Sat, 23 Jun 2012 02:43:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.94.39 with HTTP; Sat, 23 Jun 2012 02:42:23 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Sat, 23 Jun 2012 11:42:23 +0200 Message-ID: To: Aaron Bohannon Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Compiling with camlp4 extensions See the "full parser tutorial" in the Camlp4 wiki, it has information for what, if I have correctly understood, is your use case, including location handling. http://brion.inria.fr/gallium/index.php/Full_parser_tutorial On Sat, Jun 23, 2012 at 2:43 AM, Aaron Bohannon w= rote: > Thanks for the reply. =A0The example is helpful. =A0However, I should have > been more clear: I don't exactly want to write a syntax extension, per > se. =A0Rather, I am trying to use camlp4 to parse a non-OCaml grammar > and to generate an OCaml AST. =A0So the "Register.OCamlSyntaxExtension" > functor doesn't seem like it will work for me. =A0Instead, I tried using > "Printers.Ocaml.print_implem" in my "extension" code and everything > works fine, except for error locations. =A0Of course, I realize this is > because the AST is being printed and then re-parsed, but I don't know > how to prevent it from being reparsed. =A0I looked through all the > Camlp4 interfaces and thought that perhaps I need to use the function > "Register.register_str_item_parser". =A0But I couldn't make that work. > Either that's not the function I need or else I don't know how to use > it -- I can't tell which. > > =A0- Aaron > > On Fri, Jun 22, 2012 at 10:36 AM, Gabriel Scherer > wrote: >> All nodes in a Camlp4 AST are annotated with location information; the >> locations you get from the parser are correct, and it is your >> responsibility, as an extension writer, to ensure that any new nodes >> you generate also have (approximately) correct location information. >> >> If you build AST nodes "by hand", you have to provide this location >> explicitly. If you use the concrete syntax quotations, the location >> used is the value _loc present in the environment, whatever it may be. >> So to have correct locations, you have to make sure that, at every AST >> you produce through a quotation, there is a "_loc" variable in scope >> with the correct value. If you match AST pieces with quotation >> patterns (match e with <:expr< $a$ + $b$ >> -> ...), you may bind the >> location variable through the syntax "<:expr@foo<", for example: >> (match e with <:expr@_loc< $a$ + $b$ >> -> ...). Finally, if you're >> inside an EXTEND block defining a parsing rule, the idenfitier _loc is >> implicitely bound to a location corresponding to what was parsed by >> this rule. >> >> See for example the toy extension pa_refutable, that has example of >> those various things: >> =A0http://bluestorm.info/camlp4/pa_refutable.ml.html >> >> In some very rare cases (or if you are perfectionist), you may want to >> give to a new node a location that is not quite the location of any of >> the parsed node you're working on. You may use various functions of >> the Loc submodule of your syntax definition to forge new locations; in >> particular, Loc.merge merges two (supposed contiguous) locations. >> =A0http://bluestorm.info/camlp4/camlp4-doc/Sig.Loc.html >> >> >> >> >> >> On Fri, Jun 22, 2012 at 5:53 PM, Aaron Bohannon wrote: >>> Hi, >>> >>> I have been trying to use the new camlp4 to write an OCaml syntax >>> extension.=A0 All the examples I have seen so far suggest that I use the >>> extension by passing ocamlc the "-pp" option.=A0 But it seems that all = the >>> location info for error messages gets lost when I do this unless I catc= h and >>> report the parse error myself within the extension.=A0 Is there some wa= y to >>> get ocamlc to report the parse error at the correct location automatica= lly? >>> >>> - Aaron