Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
There's an elephant in the room: Solution to sharing a symbol table
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-05-02 (05:44)
From: Francois Pottier <Francois.Pottier@i...>
Subject: Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table


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