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.3 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 1CCD2BBAF for ; Sat, 10 Oct 2009 14:31:45 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0BACYb0ErRVdnjkGdsb2JhbACRRokHPwEBAQEJCQwHEwOsY4E6hi+IZQEDAwWEKASBWHKIDA X-IronPort-AV: E=Sophos;i="4.44,537,1249250400"; d="scan'208";a="48343167" Received: from mail-gx0-f227.google.com ([209.85.217.227]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 Oct 2009 14:31:44 +0200 Received: by gxk27 with SMTP id 27so7667683gxk.7 for ; Sat, 10 Oct 2009 05:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hb1asAs4VaOwghY0sYHevhG3ccpFtF2Ij6YVf/d7ChY=; b=D7qpP5H0SpaxIBglhFc9KIrk5KwBWS0BhJW50iDbdkebkCrcV70whedEGEiGGOLD1B E5iw+QYKgG0ebG+KLSLLTn2A8Z7C2T9EbSXH5BLhnDmxjKTJ8o6ajbRQPNFpt/JjU3kT viqvG8Qhu8I6Bn0LIVrTpWYusjK6cfo9d8YDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZNjYM9sjSWNit2ZyeS7qLgEg/8iAR5ZyF0IPp9W6dZalBwp4k4K9mKqa+UEDMKILBE Rflcv5+IZ1ri3siKQeQaQDjdSNKsa6lYyJ9T70GdU3HQZd18CfFnEaG+xUoKPIK3zB9L dChGDpIXKy3Gyd6glNfzDg/KvxthUW6XD13F8= MIME-Version: 1.0 Received: by 10.101.213.18 with SMTP id p18mr4215244anq.122.1255177902877; Sat, 10 Oct 2009 05:31:42 -0700 (PDT) In-Reply-To: References: <527cf6bc0910071316y233ecd35va02bfca2aa17d9c9@mail.gmail.com> Date: Sat, 10 Oct 2009 14:31:42 +0200 Message-ID: <527cf6bc0910100531w2ee13210w2351e99adb4761ec@mail.gmail.com> Subject: Re: [Caml-list] camlp5/revised syntax questions From: blue storm To: Aaron Bohannon 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 toplevel:01 ocamlfind:01 findlib:01 expr:01 topfind:01 syntax:01 expr:01 grammars:01 cmo:01 mlast:01 cmo:01 pcaml:01 On Thu, Oct 8, 2009 at 4:39 PM, Aaron Bohannon wro= te: > Thanks for your detailed reply. =A0I had a suspicion I would have to > read the source code to get the all of the necessary documentation. It is actually possible to pretty-print the grammar rules during camlp* execution. For example, here is the code I gave to the toplevel (using ocamlfind/findlib) to print the default "expr" grammar and levels : #use "topfind";; #camlp4o;; open Camlp4.PreCast;; Gram.Entry.print Format.std_formatter Syntax.expr;; This is probably camlp4-specific, but the printing routine is documented for camlp5 ( http://pauillac.inria.fr/~ddr/camlp5/doc/htmlc/library.html#b:printing-gram= mar-entries ) so an equivalent code should work. I however prefer to read the source code, wich is easier to browse and contains more information (pretty printing shows the parsing rules, but not the parse action). > However, I'm still missing some basic point here. > > On Wed, Oct 7, 2009 at 4:16 PM, blue storm wro= te: >> 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. =A0But how do you specify which grammar your > file is extending? =A0My file is structured like this: > > #load "pa_extend.cmo"; > #load "q_MLast.cmo"; > open Pcaml; > > EXTEND > =A0GLOBAL: expr; > =A0... > END; > > So where did I specify whether I was extending the original syntax or > the revised syntax (or some other grammar entirely)? =A0I suppose I must > have implicitly chosen the original syntax because my code works fine > on that. The syntax extension mechanism is imperative in nature : the EXTEND statement works on an existing grammar and add/change/delete rules (camlp5 documentation : http://pauillac.inria.fr/~ddr/camlp5/doc/htmlc/grammars.html ) : more precisely, the EXTEND syntax is a camlp4 extension itself, wich gets desugared to a bare ocaml expression wich modifies the given Grammar.Entry.t values (in an imperative way). The revised and classical syntax are designed as syntax extensions (pa_o.ml pa_r.ml) that extend an empty grammar, wich already contains some (empty) grammar entries. They first clear every entry of that grammar (probably to make sure it's really empty), then add by extension every syntaxic construct of the ocaml language. They get compiled to pa_o.cmo and pa_r.cmo, wich you can pass to camlp4 to choose one of the two syntax : camlp4 pa_o.cmo my_extension.cmo ... What happens here is that : - camlp4 starts with an empty ocaml grammar - you link it to pa_o.cmo, wich gets executed and set up the classical syntax (by mutation of the (empty) grammar entries) - you then add your own extension wich makes additional mutations In essence, the effect of your extension depends on the side effects that were done before. If pa_o.cmo or pa_r.cmo was passed as a parameter, you build upon their syntax rules, but it can be the case that an additional syntax extension was added before yours, and thus you're actually working upon slightly modified syntax rules. camlp4o and camlp4r are just packaged versions of camlp4, wich respectively "pa_o.cmo" and "pa_r.cmo" implicitly linked. In general, reasonably local syntax extension tends to work on both the classical and the revised syntax (because their syntax rules are quite similar). If your extension depends on one of the syntax, you should specify it. If your extension tries to delete a rule wich was not present in the syntax you're extending, you will get a runtime error (for example, trying to delete the "where"-related rule in the classical syntax). > 1) In the parsing rule for the simple dot noation... > > =A0 =A0 =A0| e1 =3D SELF; "."; e2 =3D SELF -> <:expr< $e1$ . $e2$ >> ] > > ...why is the field label an "expr"? =A0This 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. Is suppose this presentation was chosen to make the grammar rules simpler. Camlp4 parsers are not tied to the documented ocaml grammar. Camlp4 grammars for ocaml (you can use camlp4 to parse other languages, without necessarily starting from the OCaml grammar) use a camlp4-specific ocaml AST with then get translated to the specific AST the OCaml compiler expects (when no camlp4 preprocessing is needed, the ocaml compiler use its own yacc parser wich directly produces the ocaml-compiler AST). There are actually subtle differences in parsing (for example "let id x =3D x in id fun _ -> ()" gets rejected by the non-camlp4 parser but parses fine under camlp4 and camlp5), and I don't think any of them is "right" : they are all tied to implementation-specific parsing strategies (weird recursive descent for camlp{4,5} and yacc), and I'm not sure even the yacc version rigourously respects the documented BNF grammar. > 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. =A0So > 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. =A0I 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. I'm not sure what you mean here, but I'm under the impression that you're confusing the syntaxic representation of the expression and its runtime/compile-time semantic. Camlp* knows nothing of the meaning of the code it produces; the output is an AST wich has no idea of what a "reference" and a "value" means. The semantic of the given code depends on the deeper passes of the compiler (for example typing), wich probably have an internal language of their own, and surely make the difference between lvalue and rvalues.