On Mon, 2007-08-06 at 21:28 +0200, Hans Aberg wrote: > On 6 Aug 2007, at 12:19, tim wrote: > > >>> --no-parser would be quite useful to me. I want to use the parse > >>> tables > >>> in a lisp program. The less C code I have to filter out the better. > >> > >> It sounds you want to generate a LISP parser. Have you thought of > >> writing a skeleton file for generating LISP output, which might (some > >> day) be included in the Bison distribution? > > > If that's feasible, it's probably what I will do. The alternatives > > would > > be to write my own parser generator, or trawl through the bison > > output. > > I've printed out the M4 manual so I can understand the skeletons. > > Bison has been changed in order to facilitate that, including adding > M4, but it is hard to foresee the practical difficulties if you do > with say Lisp or Scheme. Learning whole M4 is very ambitious: one can > start tweaking the skeleton file, by comparing with the output. One > hurdle is figuring out how to translate the rather imperative style > of the parser (a so called push-down automaton to which Bison merely > computes the states) into a functional language. The parser function > checks if a new token is needed, and if there results in a reduction, > the action is performed in a large "switch" statement, and then it > loops back again, until the virtual end symbol arrives (the parser > stack has completely been reduced). The parse stack has different > components: state, semantic value, location, perhaps more, which can > be implemented as a single stack, or several. At least in the past, > the Bison skeleton file did the latter. > > Hans Aberg > >
Thanks Hans. Lisp supports programming in different ways such as functional, imperative and OO so no problem there. There is no efficient switch statement but you can get a similar effect by putting function addresses in an array. I'll let you know how I go. Tim Josling