The glue between the token list generated by the lexer, and the yeti-parser. This scanner has to perform one additional transformation, the conversion of identifiers for type names into the symbol TYPE_NAME. Why this has to be done is explained in the section defining the grammar.

The code to execute when rules are reduced by the parser. This code has to maintain at least a symbol-table, to support the lexer in his task, see above. Beyond that nearly anything will go. This could be a direct translation to machine code, the generation of an exact parse tree, generation of an abstract syntax tree, or whatever your imagination will come up with.

The generated parser. It comes in at 105 Kilobyte of Tcl code and is thus much too large for this page. And it can be generated anyways via Yeti, so there is really no reason to place it here.

GPS: This is an interesting project. What's next? Is a project page available for this somewhere(SF?)?

Currently I am toying a bit with Yeti, to make it more flexible and give me more control over the generated code. From there I would add code here to generate the parse tree of the code, and of course, management of the symbol table so that lexer and parser actually work together (see notes).

Beyond that ? I don't know yet. Things like conversion of the parse tree to a more abstract tree, type checking, ...

Way later: code generation.

SF - No, there is no project on SF about this. Well, the nearest is David Cuthbert's kt2c. This translates tcl procedures into equivalent C.

(Helmut Giese, 2004-06-30) There seemed to be a gap between the lexer from Lexing C and the parser above: As they stand these two don't fit to each other. Below is a small adapter class, which makes them compatible and a driver to combine all the pieces.

Please note, that the current version of Yeti (0.4) requires that at least one rule of the grammar has a non-empty script associated with it (but a comment suffices).

AMG: Here's a parser that goes with the alternative, ylex-based scanner found on Lexing C.

It's just a skeleton, but it does attempt to handle typedefs. typedef is the one thing preventing C from being context-free; therefore even the simplest C parser needs to implement it so it can tell the difference between an IDENTIFIER and a TYPE_NAME.

This basic implementation doesn't properly limit the scope of typedefs, so a typedef in one function will be valid in the next. Getting this right requires more smarts and may be difficult to implement in isolation. In other words, much of the necessary machinery would also be needed by a proper compiler implementation.

And here's the driver program. You will need yeti, ylex, cscanner.tcl (from Lexing C), and cparser.tcl (above). If you have trouble with mismatched braces or such, it means you need to get the very latest version of yeti which allows braces in terminal names.