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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0FEA2BC69 for ; Wed, 2 May 2007 07:44:21 +0200 (CEST) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l425iB3Y001679; Wed, 2 May 2007 07:44:11 +0200 Received: by yquem.inria.fr (Postfix, from userid 18965) id 65FBEBC69; Wed, 2 May 2007 07:44:11 +0200 (CEST) Date: Wed, 2 May 2007 07:44:11 +0200 From: Francois Pottier To: Joel Reymont Cc: Caml List , skaller , menhir-list@yquem.inria.fr Subject: Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table Message-ID: <20070502054411.GB726@yquem.inria.fr> Reply-To: Francois.Pottier@inria.fr References: <1EE80473-541D-478D-97F8-06A1B5F65F79@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1EE80473-541D-478D-97F8-06A1B5F65F79@gmail.com> User-Agent: Mutt/1.5.9i X-Miltered: at discorde with ID 4638252B.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 symtab:01 ocamlyacc:01 invocation:01 parsing:01 syntax:01 transforming:01 parser:01 run-time:01 functors:01 run-time:01 functor:01 parser:01 runtime:01 elephant:98 Hello, On Tue, May 01, 2007 at 10:39:19PM +0100, Joel Reymont wrote: > > %type Easy.program> > > program: statement EOF { fun t -> List.rev ($1 t) } > > Would this work with Menhir and would it be detrimental to performance? Yes, it would work (with ocamlyacc or Menhir). It is in fact a classic idiom. However, you must be aware that having your semantic actions build closures means that all of the actual work (e.g., the invocation of List.rev above) is delayed until *after* the entire parsing process is over. In other words, performance-wise, your code is equivalent to building an abstract syntax tree, without using your symbol table, and then transforming that tree. > I think there's an elephant in the room. Functorization of a Menhir- > generated parser doesn't solve this issue since the specialization > happens at compile time whereas a new symbol table is a run-time value. 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). -- François Pottier Francois.Pottier@inria.fr http://cristal.inria.fr/~fpottier/