Browse thread
There's an elephant in the room: Solution to sharing a symbol table
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Francois Pottier <Francois.Pottier@i...> |
| Subject: | Re: [Menhir-list] There's an elephant in the room: Solution to sharing a symbol table |
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/