Re: --no-parser options

[tim]

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