Syntax 4.2

---

• Introduction
• Sample Output
• Concepts
  • Lexic
  • Syntax
  • Context Free Languages
  • Top-down, Bottom-up
  • Context Free Grammar
  • Algorithms
• File Structure
  • Structure
  • Meta Symbols
  • Java Example
  • C Example
  • Pascal Example
  • Javascript Example
• Lexer
  • Token Definitions
  • Lexer Code
  • Code Symbols
  • Lexer Modes
  • Disambiguation
  • Writing Your Own Lexer
  • Getting Characters
  • Regular Expressions
• Production Rules
  • Learn by Example
  • Code Generation
  • Intermediate Code
  • Empty Rules
  • Rules Precedence
• Error Management
  • Error Tokens
  • Errors: C Example
  • Errors: Pascal Example
• Lexer Driven Parsing
  • Javascript Example

---

• Syntax Maven Plugin
  • Usage
  • Reference

Lexic driven parsers

---

Compiler driven parsers are the standard. They get created, invoked with an input stream, which is then read one character at a time, checking for grammar compliance and generating code and other structures as a result.

Lexical driven parsers differ in the fact that the input stream is discontinuous, usually user driven. The parser gets created and then waits for an input to come as a method call. The parser will receive the input and check it for correctness, causing shifts and reduces with the given symbol. When a state is reached that requires a new symbol, the parser will stop, store its state, and return the method call.

As part of keeping state, a lexical driven parser will be able to inform what possible symbols are available in the next method call, thus allowing user interfaces to enable/disable symbols. The typical case that I have encountered in the past was a calculator with operators, numbers and parenthesis. The buttons get enabled only on the presence of valid symbol transitions on the current parser state. Consider the following calculator:

Given the calculator UI:

  [1] [2] [3]  [+]  
  [4] [5] [6]  [-]  
  [7] [8] [9]  [*]  
  [(] [0] [)]  [/]  
        [ = ]  

Consider the following two states in an expression grammar:

State 1:  
S ->  E .  
E -> E . + E  
E -> E . - E  
E -> E . * E  
E -> E . / E  

State 2:  
E -> (  E . )  
E -> E . + E  
E -> E . - E  
E -> E . * E  
E -> E . / E  

State 1 can be seen as allowing an operator or the end of the input while state 2 shows that a parenthesis was used and thus a closing parenthesis is valid, but not the end of the input. Lets show this in the calculator diagrams. Invalid tokens in a state will be shown as periods.

For state 1:

 .   .   .   [+]  
 .   .   .   [-]  
 .   .   .   [*]  
 .   .   .   [/]  
      [ = ]  

And for state 2:

 .   .   .   [+]  
 .   .   .   [-]  
 .   .   .   [*]  
 .   .  [)]  [/]  
       ...    

Other examples have included programming languages based on button interfaces like the ones used back in the old macintosh days (Silver Surfer, or 4D, by Guy Kawasaki)