[Q]: Bison and Flex dynamic tables?

Kowsik Guruswamy <kowsik@buggy.coryphaeus.com>
17 Dec 1995 00:28:40 -0500

          From comp.compilers

Related articles
[Q]: Bison and Flex dynamic tables? kowsik@buggy.coryphaeus.com (Kowsik Guruswamy) (1995-12-17)
| List of all articles for this month |

From: Kowsik Guruswamy <kowsik@buggy.coryphaeus.com>
Newsgroups: comp.compilers
Date: 17 Dec 1995 00:28:40 -0500
Organization: Compilers Central
Keywords: yacc, lex, question, comment

Hi,


I have been toying with this idea for a long time but never found an
answer to it.


I have a parser and a scanner that's getting quite big to handle. What
I would like to do is have a core parser and scanner [core.l and
core.y say] and have a rule like the following [amongst others]:


unknownKeywordDef: KEYWORD
    {
        /*
          * Find a DSO that matches the keyword and call the appropriate parser
          */
    }


The regex for the KEYWORD would be something like:


[a-zA-Z][a-zA-Z0-9]* { strcpy (yylval.name, yytext); return KEYWORD; }


Let's say that the KEYWORD is 'hello'. When the unknownKeywordDef is
reduced, I want to call a function 'helloparse()' which has been
compiled from hello.l and hello.y


I want to push the core parser and the lexer stacks, dup the 'yyin'
file pointer, do the parsing in 'helloparse()', get back from it and
pop the stacks and get on with the parsing in 'core.y'.


This is quite important for me, because I might be adding more
keywords and hence more functionality to the core parser, without even
touching core.l and core.y.


Is this possible at all with Bison and Flex? If this is not possible,
is it possible to dynamically swap the action table?


I would appreciate any ideas or pointers, and if possible an email
reply.


Thanks,


K.
--
kowsik@coryphaeus.com
[Hacking up lex and yacc to have multiple parser tables is straightforward,
using awk scripts or the like to extract the tables from the generated code.
Personally, if what you're parsing looks to the user like one language, I'd
glom all the syntax into one yacc file both because it's easier and because
it often points out syntax ambiguities that bite users in practice. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.