Generating yacc parser/lexer

KNOWLEDGE OF YACC or BISON or ANTLR ARE REQUIRED. Without them you couldn't complete this task Hi, We need a tool/script, which could generate yacc grammar rules, based on yacc parser definitions (reductions, token actions, state actions, nonterm goto, etc). Given: 1. Generated by YACC LexerFor<N>.cpp, ParserFor<N>.cpp. They are 100% working. NO CHANGES there 2. Matchers, Transitions, States, Backups for Lexer <N> (see attachement), input#1 ([login to view URL]) 3. Reductions, Token actions, State actions, Nonterm goto, State goto for Parser <N> (see attachement), input#2 ([login to view URL]) 4. All Actions and their "mapped" values. Will send by demand, when you realise, what exactly you need here. 5. File [login to view URL], which can be parsed by existed LexerFor<N>.cpp and ParserFor<N>.cpp. Will send by demand, when you realise, what exactly you need here. 6. N ~ 20..50 (that it, we have a lot of those cpp parser/lexers) 7. Source code for extracting LEXER tokens, basing on input#1. Will send it only as a reference. You have to complete/rewrite it as well (see milestones description) Expected: Write a tool, that 1. Basing on input#1, will GENERATE proper [login to view URL] definition 2. Basing on input#2, will GENERATE proper [login to view URL] definition Milestones: 1. Basing on input#1, will GENERATE proper [login to view URL] definition (this is done somehow by me in 200 lines of c++, I could share it for reference). This milestone only shows, that you understand the problem. No source code is shipped to me, only some proof (tool binary or video). It should accept different input (I have a lot). +5% 2. You send me one of the generated .lex (as I wrote, I have a lot of inputs, I will send you 3 to 5 for video/demo, and you send me back only ONE of .lex). I will generate LexerFor<N>.cpp from this .lex, will adjust code to see that it's really works. If it is, milestone is released. +15% 3. The same with parser and .yacc. First, you prove, that it works. It should accept different input (I will send a lot of there, since it's most important part). When released, + 20% 4. Finalizing milestones. Here I will pay the rest in single or multiple releases, depending on bugs in your tool. EXAMPLE Basing on [login to view URL], your TOOL should AUTOMATICALLY output something similar to %{ #include <stdio.h> %} %% " " ; [a-zA-Z]* { return(WORD_TOKEN); } [0-9] { return(DIGIT_TOKEN); } category_define_begin { return CATEGORY_DEFINE_BEGIN_TOKEN; } category_define_end{ return CATEGORY_DEFINE_END_TOKEN; } name{ return CATEGORY_NAME_TOKEN; } .. and so on %% I have a lot of [login to view URL] and [login to view URL], all of them have different tokens and grammar rules.