190 likes | 207 Views
This informative guide covers the practicalities of CFL, CPSC 388 topics (Ellen Walker, Hiram College), grammar expressions, recursive rules, ambiguity resolution, and disambiguation methods in programming languages.
E N D
Some CFL Practicalities CPSC 388 Ellen Walker Hiram College
Grammar for Expressions • Exp -> Exp Op Exp | ( Exp ) | number • Op -> + | – | * • Non-terminals: Exp, Op • Terminals: number, +, –, *, (, ) • Terminals are tokens not necessarily characters!
Simple Grammar for Statement • Stmt -> If-Stmt | … other statements • If-Stmt -> if ( Exp ) Stmt | if ( Exp ) Stmt else Stmt • Exp -> … on previous slide
More Concise If-Stmt using • If-Stmt -> if ( Exp ) Stmt ElsePart • ElsePart -> else Stmt |
Epsilon Placement is Significant • How do these languages differ? L1: S -> x ; S | x L2: S-> x ; S | L3: S-> x ; S | A A -> x | L4: S-> N | N -> x ; N | x
Recursion in Grammars • When a rule refers to its own LHS in the RHS, the rule is recursive • Left-recursion (LHS is first) • Right-recursion (LHS is last) • “Exp -> Exp Op Exp” is both left-recursive and right-recursive!
Why Recursion? • Without recursion, languages must be finite • All possible derivations can be enumerated in advance • Example: • S-> aB • B -> b | Cc • C -> c
Recursion in Multiple Rules • Stmt -> If-Stmt | … other statements • If-Stmt -> if ( Exp ) Stmt | if ( Exp ) Stmt else Stmt • Stmt => If-Stmt => if … Stmt … • There is a recursion on Stmt, but it takes 2 rules
Ambiguous Grammars • If there is a string that has two different derivations (with different parse trees), the grammar is ambiguous. • Only one string is needed to determine ambiguity
Exp Grammar is Ambiguous • Exp -> Exp Op Exp | ( Exp ) | number • Op -> + | – | * Exp Exp Exp Op Exp Exp Op Exp Exp Op Exp Exp Op Exp number + number * number number + number * number
Dangling Else // w true when x!=0 and y=0 If (x!=0) if (y!=0) z=true; else w=true; // w true when x=0 If (x!=0) if (y!=0) z=true; Else w = true;
Disambiguating Rule • Leave the grammar ambiguous, but create a rule (outside the grammar) that determines which competing parse is “correct” • Examples: • Multiplication has precedence over addition • Subtraction is left-associative • Else matches the closest “if”
Modifying the Grammar • Create additional non-terminals and rules that prevent ambiguity • In this case, the syntax is (again) reflected only by the grammar
Exp Grammar with Precedence • Exp -> Exp Adop Exp | Term • Term -> Term Mulop Factor | Factor • Factor -> ( Exp ) | number • Adop -> + | – • Mulop -> * • * evaluation forced “deeper” into the tree!
If Grammar with “Closest else” • Stmt -> MatchedStmt | UnmStmt • MatchedStmt -> if (Exp) MatchedStmt else MatchedStmt | Other • UnmStmt -> if (Exp) Stmt | if (Exp) MatchedStmt else UnmStmt • Other -> { Stmt-list } | … | • Stmt-list -> Stmt Stmt-list | Stmt
Avoiding the IF ambiguity • Require the else part in all if’s • This is the LISP solution • Require bracketing keywords • If-stmt -> if Exp Stmt endif | if Exp Stmt else Stmt endif • In some languages “fi” is used instead of “endif”
Abstract Parse Trees • Design trees that include only essential aspects of the language (for semantics); remove “syntactic sugar” and intermediate non-terminals
Parse Tree vs. Abstract Parse Tree Exp Exp Op Exp + Exp Op Exp * number + number * number number number number
Extended BNF • “Ordinary BNF” is simply a CFG • Non-terminals named like: <expression> • Terminals are bare sequences of characters • Extensions • { x } Repeat x 0 or more times ( x*) • [ x ] x is optional (x | )