Class 15: Predictive Parsing, Concluded

Held Wednesday, October 2, 2002

Summary

Today we conclude our discussion of predictive parsing.

Notes

• Since I'd advocated that you take a stand on Darby, I started doing my own investigating, including asking for the recent document that specifies costs of various alternatives for athletics. Unfortunately, that document does not include the cost of moving Darby. I talked to Vice President Brand and he indicated that it's less a matter of cost and more a matter of feasibility (If you move it, it will collapse.)
  • Does this mean Darby must come down? No. It means we must consider tradeoffs.
  • As part of a community, you need to accept that different people will make different tradeoffs. A centralized campus center and dining facility can help Grinnell attract students, ease congestion problems at meal times, and (eventually) cut costs. It is also a type of building that people like to donate for.
  • You can (and should) actively advocate other positions.
• Since group work is one of the emphases of this class, I'd like each of you to send me a short (one-three paragraph) note on how you felt phase 1 of the project went. Did you mostly work together or build separate parts? Was the workload even or uneven? How can I support the process?
• I think that I've come up with a language not amenable to predictive parsing.
  • Consider the language aⁿbⁿ or aⁿcⁿ
  • Here's the grammar

    S -> B
    S -> C
    B -> a B b
    B -> epsilon
    C -> a C c
    C -> epsilon
    

  • Note that extra "peek-ahead" won't help, since we can always require an arbitrary amount of peek-ahead.
  • The problem: we rely on the program stack to keep track of what things are left to match. We'll learn an alternative today.

Overview

• Using an explicit stack in predictive parsing
• An extended expression example
• Problems with predictive parsing, revisited

The Predictive Stack

• Note also that predictive parsers rely on the program stack and program state to keep track of what's left to parse.
• We could make that stack explicit by pushing the stuff the RHS on the stack.
• For example, consider the improved expression grammar

  Exp ::= Term AddStuff
  AddStuff ::= addop Term AddStuff
  AddStuff ::= epsilon
  Term ::= Factor MulStuff
  MulStuff ::= mulop Factor MulStuff
  MulStuff ::= epsilon
  Factor ::= number
  Factor ::= id
  Factor ::= open-paren Exp close-paren
  

• Here are the tables

  Nonterminal	First	Follow	Nullable
  Exp	number, id, open-paren	end-of-string, close-paren	false
  AddStuff	addop	end-of-string, close-paren	true
  Term	number, id, open-paren	end-of-string, close-paren, addop	false
  MulStuff	mulop	end-of-string, close-paren, addop	true
  Factor	number, id, open-paren	end-of-string, close-paren, addop, mulop	false

• Here's a sample parser based on that grammar.

  stack.push(end-of-string)
  stack.push(Exp)
  while (input.peek() != end-of-string) {
    if stack.top() is a token 
      if stack.top == input.peek() then
        stack.pop();
        input.consume();
      else
        crash and burn
      end if // stack.top == peek()
    else // stack.top is a nonterminal
      N := stack.top;
      t := input.peek();
      switch (N,t) 
        // Exp ::= Term AddStuff
        case (Exp,number):
        case (Exp,id):
        case (Exp,open-paren):
          stack.push(AddStuff)
          stack.push(Term)
          break;
        // AddStuff ::= addop Term AddStuff
        case (AddStuff, addop):
          stack.push(AddStuff);
          stack.push(Term);
          stack.push(addop);
          break;
        // AddStuff ::= epsilon
        case (AddStuff,end-of-string):
        case (AddStuff,close-paren):
          break;
        // Term ::= Factor MulStuff
        case (Term,number):
        case (Term,id):
        case (Term,open-paren):
          stack.push(MulStuff);
          stack.push(Factor);
          break;
        // MulStuff ::= mulop Factor MulStuff
        case (MulStuff,mulop):
          stack.push(MulStuff);
          stack.push(Factor);
          stack.push(mulop);
          break;
        // MulStuff ::= epsilon
        case (MulStuff,end-of-string):
        case (MulStuff,conse-paren):
        case (MulStuff,addop):
          break;
        // Factor ::= number
        case (Factor,number):
          stack.push(number);
          break;
        // Factor ::= id
        case (Factor,id):
          stack.push(id);
          break;
        // Factor ::= open-paren Exp close-paren
        case (Factor,open-paren):
          stack.push(close-paren); 
          stack.push(Exp);
          stack.push(open-paren);
          break;
        default: 
          crash-and-burn
      end switch
    end if // stack.top is a nonterminal 
  end while
  if (stack.top != end-of-string) then
    crash-and-burn
  end if
  

• We'll find similar stacks useful in other situations.

Predictive Problems, Revisited

• Many grammars are not amenable to predictive parsing.
• Some are for languages not amenable to predictive parsing.
• Some must be mangled to permit predictive parsing.
• Neither situation is useful.
• With careful programming, we can handle use grammars to generate unmangled parse trees (e.g., yesterday's lab).
• With more lookahead, we can often do better (at keeping the original grammar and at accepting a greater range of languages).
• However, it is also instructive to look for other techniques.