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 9AF997ED45 for ; Sat, 23 Jun 2012 02:43:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUCAGEQ5U/RVda2kGdsb2JhbABFpRyQQwgiAQEBAQkJDQcUBCOCGAEBAQQSAhMZATgBAwwBBQULDS4hARIBBQEcBhMIGodbAwsLm10JA48UhQYnDUqIfgEFDIo/Y4YCA4hHjGWBEolwgyI+gVSCSQ X-IronPort-AV: E=Sophos;i="4.77,460,1336341600"; d="scan'208";a="164104806" 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 02:43:26 +0200 Received: by obbun3 with SMTP id un3so4847977obb.27 for ; Fri, 22 Jun 2012 17:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VqnWQidu09uUOhDNPS4Kd2qH4JovuOy3GRqnsWzzZlU=; b=0z3FRG9BmZ8SbsxeAow3rUfsM6geWNaW+7KtOdeqsPKqGG2wh0lcgbtunQ9Ubyh6YC C/j6U3EyDF8jTc8hy/nXUHpL84iSTvC2xPdzzLCPBfCs9ZVO/jDamcWLMAVEqV7Hw7bn br4mL6CKDgjPdUzvlgQAcAmLKaHqdSw5F15cWykJjjaOkQl/JsE1Tdh1HRLyKIvy5Qav o1gvhhOk4GMQJ1vonWyTiKP+AOfp16gr20u4zS6UduV2Ma5I7tSyK+yL9ACog9oH+fSx ogfKd2JQ0vpfazz3vQR4T0rz7mte9Aa97F7cQa/3PjRSmDUuP9QtDs8oV5LM4N0vZSxF m7qA== Received: by 10.60.30.194 with SMTP id u2mr3931553oeh.5.1340412205393; Fri, 22 Jun 2012 17:43:25 -0700 (PDT) MIME-Version: 1.0 Sender: aaron678@gmail.com Received: by 10.76.114.133 with HTTP; Fri, 22 Jun 2012 17:43:05 -0700 (PDT) In-Reply-To: References: From: Aaron Bohannon Date: Fri, 22 Jun 2012 18:43:05 -0600 X-Google-Sender-Auth: DcHDGWgzRM2jyfbMzgD1VXVfrQg Message-ID: To: Gabriel Scherer 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 Thanks for the reply. The example is helpful. However, I should have been more clear: I don't exactly want to write a syntax extension, per se. Rather, I am trying to use camlp4 to parse a non-OCaml grammar and to generate an OCaml AST. So the "Register.OCamlSyntaxExtension" functor doesn't seem like it will work for me. Instead, I tried using "Printers.Ocaml.print_implem" in my "extension" code and everything works fine, except for error locations. Of 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. I looked through all the Camlp4 interfaces and thought that perhaps I need to use the function "Register.register_str_item_parser". But 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. - 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 t= he >> location info for error messages gets lost when I do this unless I catch= and >> report the parse error myself within the extension.=A0 Is there some way= to >> get ocamlc to report the parse error at the correct location automatical= ly? >> >> - Aaron