Is it bad idea to use Flex/Bison as parser for backend of terminal emulator?

Question

I am implementing terminal emulator similar to default terminal emulator for OSX: Terminal.app.

I open terminal connection with openpty and then use Flex to parse incoming input: normal text and control sequences and Bison which calls callbacks based on tokens produced by Flex (insert string, cursor forward sequence etc).

1. Along with normal text tokens I have implemented around 30 escape sequences without any outstanding problems.
2. I made Flex/Bison re-entrant because I needed multiple terminal windows to work simultaneously
3. I did some workarounds to make Flex/Bison to read continuous output based on my another question: How to detect partial unfinished token and join its pieces that are obtained from two consequent portions of input?.

So far it looks like Flex/Bison do their job, however I suspect that sooner or later I will encounter something that reveals the fact that Flex/Bison should not be used as a tool to parse terminal input.

The question is: what are the problems that Flex/Bison can cause if they are used instead of hand-written parser for terminal input? Can performance be a concern?

Answer 1

Abbreviations are sometimes helpful:

• DPDA "deterministic push-down automata"
• DFA "deterministic finite automata"

What @ejp is saying is that bison is not needed in your solution because there is only one way that the tokens from lexical analyzer can be interpreted. The stack which was mentioned is used for saving the state of the machine while looking at the alternative ways that the input can be interpreted.

In considering whether flex (and possibly bison) would be a good approach, I would be more concerned with how you are going to solve the problem of control characters which can be interspersed within control sequences.

Further reading:

• Control Bytes, Characters, and Sequences