English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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