**** problems that can occur in recursive-descent parsing (skip)
***** left-recursion (skip)
------------------------------------------
       PROBLEM: LEFT RECURSION

Consider:

  <Exp> ::= <Exp> + <Number> | <Number>

Parsing function for <Exp>:

void parseExp() {
   parseExp();
   eat(plussym);
   eat(numbersym);
}

Is that a problem?



------------------------------------------
        ... yes, it's an infinite loop!

------------------------------------------
       ELIMINATING LEFT RECURSION

Technique: change to right recursion,
  using a new nonterminal

E.g., change

  <Exp> ::= <Exp> + <Number> | <Number>

to





------------------------------------------
  ...
<Exp> ::= <Number> <PlusExpStar>
<PlusExpStar> ::= + <Number> <PlusExpStar>
           | <empty>

 or (using the meta-notation from EBNF):

<Exp> ::= <Number> { <PlusExp> }
<PlusExp> ::= + <Number> <PlusExp>

      Q: How do you know you haven't changed the language?
      Should check that this generates the same set of strings...
         unfortunately, this is an undecidable problem!

      However, when there are productions of the form
          <X> ::= <X> g | a
          where g and a stand for strings of terminals and non-terminals
                and a does not start with <X>,
      then this derives strings of the form: a g* (as a regular expression),
      so we can write this RE as a regular grammar using right-recursion: 
          <X> ::= a <X2>
          <X2> ::= g <X2> | <empty>

***** left factoring (skip)
------------------------------------------
      PROBLEM: AMBIGUOUS START OF RULES

Example:
   <S> ::= if <E> then <S> else <S>
        |  if <E> then <S>

If we see an if token, which one to parse?


       SOLUTION: LEFT FACTORING
         
Tactic:
  - Put common start in 1 nonterminal
  - Put differences in another nonterminal

Example:




Why is this better?




------------------------------------------
    ... <S> ::= if <E> then <S> <ME>
        <ME> ::= <empty> | else <S>

    ... because parseME can be written to check the next token
         (e.g., if it's an else, then parse the next statement,
                otherwise done with it)

**** case study: PL/0 expressions
------------------------------------------
   CASE STUDY: PARSING PL/0 EXPRESSIONS

Grammar for <expr> in PL/0:

<expr> ::= <term> { <add-sub-term> }
<add-sub-term> ::= <add-sub> <term>
<add-sub> ::= <plus> | <minus>
<term> ::= <factor> { <mdf> }
<mdf> ::= <md> <factor>
<md> ::= <mult> | <div>
<factor> ::= <ident> | <num>
         | <sign> <num> | ( <expr> )
<sign> ::= <plus> | <minus>

Examples in the language of <expr>:

   +3402
   -3402 + 4020
   3*4+2
   3*4+(0+(1+1))

------------------------------------------
        Note: <empty> was missing from <sign> in the original grammar...

        Q: Why isn't the grammar like <expr> ::= <expr> <op> <expr>?
           First, that has left recursion,
           Second it's highly ambiguous.
           
        Q: How is 3*4+2 parsed?
        Like (3*4)+2, since multiplication is a <factor>

------------------------------------------
       PARSE TREE WITH THIS GRAMMAR











       3     *      4        +      2
------------------------------------------

             <expr>
             /     \
          <term>    <add-sub-term>
         /    \           \     \
    <factor> <mdf>    <add-sub> <term>
       |     /   \          \      \
     <num> <md> <factor>  <plus> <factor>
       |     |      |        |      |
       3  <mult> <num>       +    <num>
             |      |               |
             *      4               2


        Q: Could we have made a different parse tree?
           No, there's no choices to make
           (Note: we are expanding { X } with as many copies as we need)

        Q: What are the tokens here?
           <num>, <mult>, <num>, <plus>, <num>, ...

        Q: How do we start writing this?
        start with parseExpr()...

------------------------------------------
         CODE FOR PARSING EXPRESSIONS

// assume advance() and eat(), as before

void parseExpr()
{








void parseSign()
{


  
------------------------------------------
... // parseExpr body:
    parseSign();
    parseTerm();
    parseAddSubTermList();


... // parseSign body:
    switch (tok.typ) {
       case plussym:
          eat(plussym);
          break;
       case minussym:
          eat(minussym);
          break;
    }