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=1.9 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 70807BBC4 for ; Sat, 21 Mar 2009 18:24:32 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4DAMu/xElKfSweimdsb2JhbACVL0EBCgkTDwWuG4EHjmMBAwEDg3sG X-IronPort-AV: E=Sophos;i="4.38,400,1233529200"; d="scan'208";a="24715685" Received: from yx-out-2324.google.com ([74.125.44.30]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Mar 2009 18:24:31 +0100 Received: by yx-out-2324.google.com with SMTP id 8so905257yxb.27 for ; Sat, 21 Mar 2009 10:24:30 -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=wcgQaCWur1yWmDYOktw1p34CdaxA3fsd2O4a7BUoJ2s=; b=ahFvGni4f9z9++wT9iM2cF+z++MVoUwL7NS5649lHVHlnzDRBLcBzpAIX8phh5ska7 ao1VepyJDTNl6OykgSkiilWjb7lXLASFAF6ODoxAiC9G6yJ1bY1Hsuy2xQVcJrcKOdnC whYcq4wYecuyz/OEgOD2PNt8jijmp3buCQw/I= 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=B+TEoie/eznlr0iIZLmIJE9GHgts+pVJqeC09Idb5HN5W5tHRb5ugcvGvlV7dH3DlR e+oG9lLJ7OnfJQey1MjL2gMJTG4xJmq1Hfl12bLNvXxFluTfmB4a6C1p9+QBQC/bwZRE pAj6GeGDW1/tEeLsI4S6oPFBF8G73XGVEg724= MIME-Version: 1.0 Received: by 10.150.140.6 with SMTP id n6mr8925034ybd.248.1237656270528; Sat, 21 Mar 2009 10:24:30 -0700 (PDT) In-Reply-To: <1237652076.6137.15.camel@homesick> References: <1237606863.5943.0.camel@homesick> <527cf6bc0903210826r5a0c079bm71068f5b1d89ebe1@mail.gmail.com> <1237652076.6137.15.camel@homesick> Date: Sat, 21 Mar 2009 18:24:30 +0100 Message-ID: <527cf6bc0903211024n11ab84c2u940c8b64ad7f2582@mail.gmail.com> Subject: Re: [Caml-list] Camlp4 help From: blue storm To: Andre Nathan Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; camlp:01 expr:01 expr:01 nodes:01 translating:01 node:01 camlp:01 translating:01 nodes:01 -like:01 storm:98 nathan:98 wrote:01 caml-list:01 ident:01 On 3/21/09, Andre Nathan wrote: > I think I understand, although I thought the "x = expr" rule in the sum > form definition meant that before "plus" any expression would be > allowed. What you wanted is let a = b in (a plus b). The expression is not before plus, plus is inside the expression. Your rule means that inside plus, the left member can be an expression (eg. (let a = b in a) plus b). > I want to allow any expression inside a "sum" block, which I think I > could do by defining it as a new rule in "expr", but I'd like "plus" > expressions to only be allowed inside a "sum" block, which I'm not sure > how to do. I see (but there may be a better choice) two solutions : - create a new structure expression_inside_sum wich is a complete copy of "expr" with sums added. This is ugly and redundant. - use a "marker" trick in two pass : - in your grammar you "mark" plus nodes by translating them into a specific AST node (wich cannot be produced by any usual camlp4 construct), for example "a plus b" -> <:expr< $id:"camlp4.plus"$ a b >> - then you use an Ast.map or a Camlp4Filter to explore the resulting AST, translating the marked nodes (the ones with "camlp4.plus" as identifiers) into different things depending on wether you're inside a sum-block or not (or possibly raising an error outside a sum-block). If you want an example, I used a similar trick in my "pa_holes" extension : "\1"-like identifiers are allowed only inside a (\ ... ) block; at first they're allowed everywhere (the "ident" rule is changed), then they're transformed into a valid camlp4 construction inside the (\ ... ) blocks ("expr" rule), and finally the AST is explored and any remaining \n raise an error (Remove_holes filter). This solution is also ugly, but has little redudancy.