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.5 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 363B2BC37 for ; Wed, 14 Oct 2009 04:04:13 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUCAG/O1ErRVdjHi2dsb2JhbACPUop2PwEBAQoLCgcRBa13MoY7I4hCAQMDBYQoBIFbhx4 X-IronPort-AV: E=Sophos;i="4.44,554,1249250400"; d="scan'208";a="38188837" Received: from mail-px0-f199.google.com ([209.85.216.199]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Oct 2009 04:04:12 +0200 Received: by pxi37 with SMTP id 37so624232pxi.15 for ; Tue, 13 Oct 2009 19:04:11 -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=MSAkfhcf01isOPcC3u904uGqmNiY0iCJes53VVTMgiY=; b=nh7VJegU0gioXLwIZOKtzaikl6MJ/vjIdAE4Iw/baMzZQgCqvyLBqWP77c+NN/e7t0 rMhIbZbSMWzptNZ/XkiKcbOV+fjCXNw7Fodp8lESBOCq5akHAQV3qK7/W/O91f9xcOvb vE4yiamJNJYocL6+HOxPTiUCy8YGgwUTHyJ58= 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=HJYyDOI/JsR32sgEtj2z6d0X4Phb5agw8sQPKnB8MTEx8jSJ2lns8eFqKV/qZ03mTW jHKeVAwjLulDawIkuKsuT+baGPUFA0kqopiDk3RiiyYHSwQqcgCEkOhJ9Wp7N8w9uxAp NFGEJqaXrABmfRaJ2RzCeXfOHyKGvGWDgLpXc= MIME-Version: 1.0 Sender: aaron678@gmail.com Received: by 10.142.60.5 with SMTP id i5mr657524wfa.102.1255485851425; Tue, 13 Oct 2009 19:04:11 -0700 (PDT) In-Reply-To: <527cf6bc0910100531w2ee13210w2351e99adb4761ec@mail.gmail.com> References: <527cf6bc0910071316y233ecd35va02bfca2aa17d9c9@mail.gmail.com> <527cf6bc0910100531w2ee13210w2351e99adb4761ec@mail.gmail.com> Date: Tue, 13 Oct 2009 22:04:11 -0400 X-Google-Sender-Auth: 870e0fd672b95e71 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 syntax:01 ocaml:01 cmo:01 cmo:01 camlp:01 ocaml:01 mutation:01 parser:01 runtime:01 compile-time:01 compiler:01 foo:01 mutable:01 On Sat, Oct 10, 2009 at 8:31 AM, blue storm wrot= e: > 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 : > =A0camlp4 pa_o.cmo my_extension.cmo ... > > What happens here is that : > =A0- camlp4 starts with an empty ocaml grammar > =A0- you link it to pa_o.cmo, wich gets executed and set up the > classical syntax (by mutation of the (empty) grammar entries) > =A0- you then add your own extension wich makes additional mutations Ah. I didn't understand that you can (and must) compile syntax extensions without committing to which grammar you are extending. Sequencing the "cmo" files as arguments to "camlp4/5" makes enough sense. Things seem a little more magical when loading extensions with the "#load" directive because it seems the parser has to change its behavior while it's in the middle of parsing, but at least I've got the basic idea now. > 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. OK. I wasn't very precise. I meant that, with those parsing rules, there must be a sort of error that is generated after parsing, but before type-checking. For instance, let's say we have type foo =3D { mutable bar : int; } Then, according to the grammar, there is no parse error in the expression { bar =3D 3 } . "bar" But I don't know of what OCaml type error this is supposed to generate either. And as I wrote this, I realized it's quite easy to try this out and see what happens. What we actually get (using camlp5o) is: Failure: lowercase identifier expected Similarly, you can try this expression "foo" <- 3 and you will get Failure: bad left part of assignment I guess that, in practical terms, these are just parse errors, too. However, they are still a bit mysterious since they get generated on expressions that conform to the grammar. Poking around the camlp5 sources, it appears the errors are generated by camlp5, which means these expressions probably do not represent valid OCaml ASTs. In that case, I find camlp5's grammar design a little puzzling. - Aaron