Re: How to use flex/bison with an inverted flow of control?

I can't recall if anyone ever did an inverted flow-of-control version
of bison and flex--I don't think anyone has. Yacc++ (see my .sig) was
specifically written to do inverted flow-of-control (and in fact, we
use wrapper functions to simulate the "normal" flow-of-control).


BTW, doing inverted flow-of-control is one of the few advantages of
bottom-up (e.g. LR) parsing. You could write a table driven top-down
(e.g. LL) parser, but not a recursive descent one. In an recursive
descent parser, one depends on the "call stack" to carry certain
information. If you are constantly interrupting that stack (and
returning to some caller outside the RD chain), you destroy that
information. One needs an explicit (software controlled) stack that
one can manually push and pop as needed to do inverted
flow-of-control.


Note, an alternative work-around to cope with not being able to do
inverted flow-of-control is to split the process into two threads.
One thread produces the tokens and the other consumes (parses) them
with a semephore in between to synchronize the threads. BTW, this is
nromally synchronized even lower with the producer creating a text
stream and the consumer reading characters, lexing, and parsing. You
should be able to find instances of this around. I recall projects
which used this technique with both PCCTS and with flex/bison.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
[Since you don't need or want a parser to run asynchronously, rather
than a thread library you might look for a simpler coroutine library
and just package up the parser as a coroutine that flips back and forth
inside yylex(). -John]

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