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.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id AC141BC6C for ; Wed, 2 May 2007 07:58:49 +0200 (CEST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l425wn63004325 for ; Wed, 2 May 2007 07:58:49 +0200 Received: by ug-out-1314.google.com with SMTP id k3so149758ugf for ; Tue, 01 May 2007 22:58:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Z7rMTVQDkYXJANLQOiKTRtUumvTLrlPrsMiJASW2hp/UJnvwwVvdbx9XvTd4OTo3JSoEi7R0xBE1NTZP6aJvfk3Aqqplrl7X9Wy4ZYgLbWC72MkGRltqfjYAd2oOAtxQt1itgq2h2fAOTL6WTHT2OScqcFmC7zmuswBNhQPCe5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Gb54tTEK4p2PKoI8MdWFQYzg9lH+hV9aCQpc5mhjP6UbJWdbgJhkjvc3wUyudaPkyU+KiXj4YGlPsHKdypby2miYINMfhIFQaHno6aNRTQJPBT69e9ey7eK2ng2eLeduG4lWd2pZw+tNGbi4uHg/kuq+o2Iz8graYBWabJm1qNg= Received: by 10.82.187.16 with SMTP id k16mr651854buf.1178085529041; Tue, 01 May 2007 22:58:49 -0700 (PDT) Received: from ?192.168.1.34? ( [83.52.237.136]) by mx.google.com with ESMTP id z40sm1347717ikz.2007.05.01.22.58.47; Tue, 01 May 2007 22:58:48 -0700 (PDT) In-Reply-To: <20070502054411.GB726@yquem.inria.fr> References: <1EE80473-541D-478D-97F8-06A1B5F65F79@gmail.com> <20070502054411.GB726@yquem.inria.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C011A98-CE76-4A83-B24C-BA37B66DF15D@gmail.com> Cc: Caml List , skaller , menhir-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Joel Reymont Subject: Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table Date: Wed, 2 May 2007 06:58:47 +0100 To: Francois.Pottier@inria.fr X-Mailer: Apple Mail (2.752.3) X-j-chkmail-Score: MSGID : 46382899.001 on discorde : j-chkmail score : XXX : 5/20 1 0.000 -> 3 X-Miltered: at discorde with ID 46382899.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; functors:01 run-time:01 functor:01 parser:01 runtime:01 lexer:01 parser:01 lexbuf:01 lexing:01 lexbuf:01 lexer:01 lexing:01 curried:01 parsing:01 elephant:98 On May 2, 2007, at 6:44 AM, Francois Pottier wrote: > Functors can be applied at run-time (via "let module"), so a > functor parameter > *can* provide a parser with runtime information. I would still > recommend the > %parameter approach, since it is syntactically lighter and more > efficient (the > semantic actions won't be delayed). I have been butting my head against this for a few days now. Please, please provide an example!!! I'm not talking about a general example of a %parameter approach but an example of using that approach with a lexer. Consider this function that should parser a string and return an AST: let parse str = let lexbuf = Lexing.from_string str in program (token tab) lexbuf The token lexer above takes a tab argument before lexbuf but program always expects (Lexing.lexbuf -> token) so we give program the curried function. How do you write parse above with the %parameter approach to ensure that parse ALWAYS uses a new symbol table that is shared between the lexer and the parser in this parsing run? Thanks, Joel -- http://wagerlabs.com/