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=2.4 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id AB8D4BBAF for ; Thu, 8 Oct 2009 16:39:53 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncBAKiWzUrRVdS/imdsb2JhbACaQT8BAQEICwwHEQWwDjKGPohEAQMDBYQlBIFYZoYY X-IronPort-AV: E=Sophos;i="4.44,525,1249250400"; d="scan'208";a="35951358" Received: from mail-vw0-f191.google.com ([209.85.212.191]) by mail3-smtp-sop.national.inria.fr with ESMTP; 08 Oct 2009 16:39:52 +0200 Received: by vws29 with SMTP id 29so3360741vws.15 for ; Thu, 08 Oct 2009 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=CHo7zrEOMNBPDdfTf6aqmtp6UwDu+ye+ThvN3HM/rmQ=; b=jRMEGHHR6PKTtX+T7l19qlV+kkKXg5lpzObYYgbqHorlWfUDu+oMzQv1/bRtlmV8G6 zgevchg54TAyTBS9JFP0fHBcpoLeSjdqyBoWjHOyjAzkLJoRf80B6kd0dc7rRh9BEX30 1zdBu5rY3T670Abh8Xoi8ZkOcNR07QYmcC3t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pRe7AQ9hzk0Z3zAZgk4esRTw54rmyFGuXndiFP7Zkj9zVaAzCLmfTm0ge/0dG+qqif 793wWXawQrUo5sw3P1tRJTf7yLW+ONZIFgL7R6fM7yJ/op9yP5pU+f9mCZU98NcgQ9wA mucvu02EEZhOzjHcgN/eGYHpDITG07kGs3U58= MIME-Version: 1.0 Sender: aaron678@gmail.com Received: by 10.220.103.15 with SMTP id i15mr2247534vco.15.1255012791366; Thu, 08 Oct 2009 07:39:51 -0700 (PDT) In-Reply-To: <527cf6bc0910071316y233ecd35va02bfca2aa17d9c9@mail.gmail.com> References: <527cf6bc0910071316y233ecd35va02bfca2aa17d9c9@mail.gmail.com> Date: Thu, 8 Oct 2009 10:39:51 -0400 X-Google-Sender-Auth: 0213ab5ceadc10e1 Message-ID: Subject: Re: [Caml-list] camlp5/revised syntax questions From: Aaron Bohannon To: blue storm Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; camlp:01 syntax:01 camlp:01 grammars:01 cmo:01 mlast:01 cmo:01 pcaml:01 expr:01 syntax:01 syntaxes:01 ocaml:01 expr:01 val:01 ocaml:01 Thanks for your detailed reply. I had a suspicion I would have to read the source code to get the all of the necessary documentation. However, I'm still missing some basic point here. On Wed, Oct 7, 2009 at 4:16 PM, blue storm wrote= : > The different "level names" are not absolute among all camlp4 grammars > : they're a property of each grammar rule of each grammar. If you want > to "modify" a specific grammar (that is, EXTEND it), you must check > the different levels available in the definition. Yes, I understand that. But how do you specify which grammar your file is extending? My file is structured like this: #load "pa_extend.cmo"; #load "q_MLast.cmo"; open Pcaml; EXTEND GLOBAL: expr; ... END; So where did I specify whether I was extending the original syntax or the revised syntax (or some other grammar entirely)? I suppose I must have implicitly chosen the original syntax because my code works fine on that. > While concrete syntaxes for revised and classical syntax are > different, the abstract syntax tree is the same. Camlp4 quotations > works by replacing (using camlp4) the quotation you wrote by the > concrete ocaml AST representation. Yes, this point is crystal clear, and I have no problem writing the quotations in the revised syntax. > In your specific case, you can parse whatever syntax you want using > the "<-" operator, then output the corresponding AST using a quotation > in the revised syntax, that is <:expr< a :=3D b >> (instead of "a <- > b"). For a reference, see the related rules in etc/pa_o.ml : > > =A0| ":=3D" NONA > =A0 =A0[ e1 =3D SELF; ":=3D"; e2 =3D expr LEVEL "expr1" -> > =A0 =A0 =A0<:expr< $e1$.val :=3D $e2$ >> > =A0 =A0| e1 =3D SELF; "<-"; e2 =3D expr LEVEL "expr1" -> > =A0 =A0 =A0<:expr< $e1$ :=3D $e2$ >> ] Thanks, I found this piece of code. Now on a more specific point, I am confused about the parsing of record access and update: 1) In the parsing rule for the simple dot noation... | e1 =3D SELF; "."; e2 =3D SELF -> <:expr< $e1$ . $e2$ >> ] ...why is the field label an "expr"? This does not agree with the OCaml manual, which has a separate syntactic category for "field" (http://caml.inria.fr/pub/docs/manual-ocaml/expr.html), nor with my intuition about the meaning of the code. 2) Furthermore, as one can see from the ":=3D" entry above, the entire left side of a record update is parsed as its own subexpression. So this means, that in the context of a record update, that subexpression has to be interpreted as a reference, but in other contexts, the very same expression must be interpreted as a value. I don't necessarily care what kind of magic makes this possible on the back end, but I am wondering whether this has any implications for modifying the record syntax. - Aaron