A Push-Parser can be generated with the help of the Push-Skeleton.
Use (Why!):
A parser requires tokens as input. These tokens are procured through a lexical analyzer. Usually the syntax analyzer and the program section that called the syntax analyzer are blocked as long as the lexical analyzer is busy procuring tokens. In many situations, this blocking is unwanted. The parser's runtime comprises the runtime of its state-machines plus the runtime of the lexical analysis, which is dependant on the availability of input data. This operational principle characterizes a conventional parser and describes the pull-principle.
In complex systems, it is impossible to implement a pull-parser for syntax analysis of a data stream because the entire program is blocked when no data is ready on the data stream. Consequently, it is impossible to implement a pull-parser for the syntax analysis of network protocols. This leads to the deployment of hand-written parsers that usually don't take into account state-machine theory, making it impossible to prove if the parser functions correctly. Also, most hand-written parsers are not reusable, are not easily maintainable, and are not secure.
It is possible to place a pull-parser in its own process or thread, but this creates other problems - inter-process communication and synchronization, respectively. This unnecessarily complicates the program. The one-process alternative is the push-parser.
Push-Parser:
The calling order of the lexical analyzer and the syntax analyzer is opposite that of a pull-parsers, which follows the theoretical calling order. The push-parser remains inactive until it is called from the lexical analyzer. This means that a push-parser won't call the lexical analyzer to receive the next token. Instead, the parser expects the token to be passed as a parameter. When this token is processed, the push-parser returns to the lexical analyzer. This means that the push-parser will only be called when a token is available. The parser runtime is reduced to the runtime of the stack state-machines O(D), where D=Depth of the stack. The lexical analyzer sends tokens to the push-parser until the parser stops with an error and doesn't accept any new tokens. To keep the push-parser interactive, it is necessary the no blocking actions be performed inside of the semantical analysis. This programming model doesn't affect the parser state-machines in any way. This means that the state-machines and their function methods in a push-parser are identical to those of a pull-parsers, leading to identical output by identical input. Consequently, a push-parser is a complete replacement for a pull-parser, with the advantage that it can be deployed in an event-driven environment.
Push-Lexer:
A push-parser requires a push-lexer. The function of a lexical analyzer is to recognize a token from a symbol buffer. How the buffer is filled with symbols is not part of the lexical analyzer. The caller passes a symbol buffer to the push-lexer when it is called. When the buffer is processed, it is returned to the caller. Several methods can be used to fill the buffer with symbols inside of the caller, the select function for example.