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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 939E8BC6C; Wed, 2 May 2007 18:07:32 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l42G7Ta4005091; Wed, 2 May 2007 18:07:30 +0200 X-IronPort-AV: E=Sophos;i="4.14,480,1170595800"; d="scan'208";a="122467359" Received: from ppp8-148.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.8.148]) by ipmail01.adl2.internode.on.net with ESMTP; 03 May 2007 01:37:27 +0930 Subject: Re: [Caml-list] Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table From: skaller To: Francois.Pottier@inria.fr Cc: Caml List , menhir-list@yquem.inria.fr In-Reply-To: <20070502115635.GA21560@yquem.inria.fr> References: <1EE80473-541D-478D-97F8-06A1B5F65F79@gmail.com> <20070502054411.GB726@yquem.inria.fr> <8C011A98-CE76-4A83-B24C-BA37B66DF15D@gmail.com> <1178096690.13660.80.camel@rosella.wigram> <20070502115635.GA21560@yquem.inria.fr> Content-Type: text/plain Date: Thu, 03 May 2007 02:07:26 +1000 Message-Id: <1178122046.6486.31.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4638B741.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 functor:01 functors:01 lexer:01 parser:01 parsing:01 parser:01 ocamllex:01 recursive:01 functor:01 recursive:01 parses:01 stack:01 lexer:01 ocamlyacc:01 On Wed, 2007-05-02 at 13:56 +0200, Francois Pottier wrote: > Hello, > > On Wed, May 02, 2007 at 07:04:50PM +1000, skaller wrote: > > You can't. Don't be confused by functor interface in Menhir. > > It is useless for maintaining state. > > I don't think so... State must be maintained in function arguments. Functors are entirely irrelevant. This is about associating data with a thread of control. Joel asked: "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?" and the answer is you have to pass an argument to the parser function. > > What you need is a feature I asked for .. the possibility of > > passing a state argument to the parser the same way you can > > now do for ocamllex: you just write > > > > rule fred state = parse ... > > I remember our discussion. What you need primarily, if I recall > correctly, is the ability for a semantic action to recursively > invoke the parser itself. This happens to work if the parser is > defined as a recursive function, and does not (currently) work > when the parser is defined as a functor, because the functor is > not declared as recursive. We could, in principle, make it a > recursive functor, which would allow recursive invocations. Let me give you a real example: I have a parser that reads Felix code that looks like: fun f .. // felix stuff include "filename"; fun g .. // When the parser sees the include statement it parses the file 'filename'. The parse of the included file, in Felix, is independent of the surrounding code. The parser is called recursively and the resulting AST is returned from the user action. There is no way to do this without passing a state variable on the stack. In fact Felix uses a variable passed to the lexer to work around the deficiency in Ocamlyacc .. it passes the variable to the parser in a token .. :) [That works with Menhir too by the way] -- John Skaller Felix, successor to C++: http://felix.sf.net