Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table

[Francois Pottier <Francois.Pottier@inria.fr>]

Hello,

On Tue, May 01, 2007 at 10:39:19PM +0100, Joel Reymont wrote:
> 
> %type <Symtab.t -> 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/