Outline

• Techniques for Making CFGs
• CFG Ambiguity
• Brute Force Parsing
• s-grammars
• Quiz

Introduction

• Before the midterm we had just started talking about context-free grammars (CFGs).
• A CFG is a 4-tuple `G=(V, Sigma, R, S)` where `V` is a set of variables, `Sigma` is an alphabet, `R` is a set of rules (aka productions) of the form some variable `->` some string of variables or terminals, and `S in V` is the start variable for the CFG.
• We abbreviate rules with the same left hand side variable using `|`. So the two rules `S->A` and `S->B` could be abbreviated as `S->A|B`.
• Strings in `Sigma^{\star}` can be derived using `G` from the start variable via a finite sequence of substitutions (yield steps).
• For example, if `S` is the start variable and our rules were `S -> SS | (S) | epsilon`, then we can derive/generate the string `(()())` using
  `S => (S) => (SS) =>((S)S) => (()S) => (()(S)) => (()())`.
• The set of strings derivable from a CFG is called its language. A language derivable by a CFG is called a context-free language (CFL).
• One of the starting points in specifying a modern programming language is to come up with a grammar for it.
• Today, we begin by considering techniques for creating useful conteext free grammars.

Techniques for Designing CFGs

• Many CFLs are the union of simpler CFLs. So one can design a CFG for each in turn with start states say `S_1, S_2, ldots, S_n`. Then take the union of the rules and add a new start variable with a rule `S -> S_1| S_2|ldots |S_n`. For example, take the language `{0^n1^n | n geq 0} cup {1^n0^n | n geq 0}`. First we could make CFGs for each language separately. Say, `S_1 -> 0 S_1 1|epsilon` and `S_2 -> 1 S_2 0|epsilon`. Then add the rule `S -> S_1| S_2`.
• Notice any regular grammar is already a CFG, so the regular languages are all CFLs.
• For a CFL which contains two sub-strings which are linked in the sense that a machine for such a language would need to remember information about one of the strings to verify information about the other substring (for example, open and close parentheses), you might want to consider rules of the form `R -> u R v`. Here `u` and `v` should satisfy the property you are trying to verify.

Intuitions about Compilers

• Recall compilers take strings written in a high level language like C or Java and spit out code in machine language.
• So a compiler's job is to assign machine code "meaning" to a string written in C.
• The C language might be specified using a CFG.
• For instance, we might have a rule like:
  `< mbox(while statement)> -> whi\l\e <mbox(expression)> <mbox(statement)>`
• Crudely, we could imagine writing a recursive program to handle this:
  

  int parseWhile(String program, int whereParsing, MachineCode whileCode) {
      MachineCode expressionCode = new MachineCode();
      MachineCode statementCode = new MachineCode(); 
      whereParsing += 5; //advance past the keyword 'while'
      whereParsing = parseExpression(program, whereParsing, expressionCode); 
      whereParsing = parseStatement(program, whereParsing, statementCode);
      // some code to build whileCode from expressionCode and statementCode 
      return whereParsing;
  }
  

• The underlying assumption for compilation to work is that there can be only one machine code meaning one can give to a given C string. Here we have to be careful...

Ambiguity

• Sometimes a grammar can generate a string in more than one way.
• Such a string will have several different parse trees. As the parse tree is supposed to give us the "meaning" of the string, such a string would have more than one meaning.
• A string with more than one parse tree with respect to a grammar is said to be ambiguously derived in that grammar.
• For example, consider `<EXPR> -> <EXPR>+ <EXPR>| <EXPR> times <EXPR>|(<EXPR>) |a`.
• Then a + a x a can be derived with two different parse trees:
  
• The left tree probably means `a+(a times a)`; whereas, the right means `(a+a) times a`

Leftmost and Rightmost Derivations

• We want to formalize the notion of ambiguity in terms of derivations rather than parse trees as derivations are easier to work with syntactically.
• We say that a derivation of a string `w` in a grammar `G` is a leftmost derivation if at every step the leftmost remaining variable is the one replaced.
• We say that a derivation of a string `w` in a grammar `G` is a rightmost derivation if at every step the rightmost remaining variable is the one replaced.
• As an example, if our CFG was `A ->\B\A\C | epsilon`, `B -> b, C->c`. Then `A=>\B\A\C => \b\A\C => \b\B\A\C\C => \b\b\A\C\C => \b\b\C\C => \b\b\c\C => \b\b\c\c`, is a leftmost derivation of `\b\b\c\c`.
• On the other hand, `A => \B\A\C => \B\A\c => \B\B\A\C\c => \B\B\A\c\c => \B\B\c\c => \B\b\c\c => \b\b\c\c` would be a rightmost derivation of the same string.
• Intuitively, if we have two ways to expand the leftmost (respectively, rightmost) symbol then the derivation will be ambiguous.

Ambiguity and Leftmost Derivations

• A string `w` is derived ambiguously in `G` if it has two or more different leftmost derivations (resp. rightmost derivations). A CFG is called ambiguous if it generates some string ambiguously.
• In the case of a + a x a, the two left most derivations are:
  1. `<EXPR> =><EXPR> + <EXPR> => a + <EXPR>`
     `=> a + <EXPR> times <EXPR> => a+a times <EXPR> =>a+a times a`
  2. `<EXPR> => <EXPR> x <EXPR> => <EXPR> + <EXPR> times <EXPR>`
     `=> a + <EXPR> times <EXPR> =>a+ax<EXPR> => a+a times a`
• There are often many different CFGs for the same language. Even though one of these may be ambiguous some other may be unambiguous. We say a language is inherently ambiguous if one can never find an unambiguous CFG for it. The book says without proof that `{a^ib^jc^k| i=j \ mbox{or} \ j=k}` is inherently ambiguous.

Brute Force Parsing

• One way to do parsing is by exhaustive search.
• We consider each one step derivation from the start variable, then each two step derivation, etc. in turn.
• If we ever see the string we want we accept.
• If all the active derivations involve strings of terminals and variables longer than the string w we are searching for, we halt and reject.
• To handle rules like `A->B`. Which can give derivations like `A => B => A`, we maintain a list of strings we have already seen. If we repeat, we prune that branch.
• This is an exponential time algorithm; whereas, if we use a normal form for our grammars we can speed things up to be either cubic or in some cases linear time.

s-grammars

• We would like parsing algorithms which run in linear time.
• One way to achieve this is to restrict the kind of grammars we consider:
  Definition. A context-free grammar `G=(V, T, P, S)` is said to be a simple grammar or s-grammar if all its productions are of the form: `A -> ax` where `A in V`, `a in T`, `x in V^star`, and any pair `(A,a)` occurs at most once in `P`.
• For example, `S ->aS|bSS|c` is an s-grammar, but `S ->aS|bSS|aSS|c` is not because `(S,a)` occurs in `S ->aS` and `S ->aSS`.
• Our brute force parsing algorithm will run in linear time with an s-grammar since at any given step there is at most one production which can be used. Further since the right hand side of a production always starts with a terminal we match at least one character of the input with each substitution.
• So after at most linearly many substitution we know if the string is in the language.
• s-grammars tend to be too restrictive to specify practical programming languages; nevertheless, they show the form of the rule is important to get efficient parsers.

Quiz

Which of the following is true?

1. There is no known algorithm for checking if a regular language is non-empty.
2. The proof of the pumping lemma was a proof by induction.
3. The language of the context-free grammar: `A -> 0A1`, `A -> B`, `B -> epsilon` is non-regular.