Thu Nov 18

parsing

Let's do one more round of discussing what "recursive descent parsing" is all about.

This time let's do some live coding with python ... just for a change, using a simple example.

Consider this "fully parenthesized expression" grammar; let's call it FPE. (Adapted from an idea in these notes.)

expression ::=  "(" expression operator expression ")" | number
operator   ::=  "+" | "-" | "*" | "/"
number     ::=  digit digit*
digit      ::=  "0" | "1" | "2" | "3" | "4" |
                "5" | "6" | "7" | "8" | "9"

Here are a few sample expressions :

1
(1+2)
((12+34)*(56-78))

And a few full parse trees :

['expression', ['number', ['digit', '1']]]

['expression',
   '(',
   ['expression', ['number', ['digit', '1']]],
   ['operator', '+'],
   ['expression', ['number', ['digit', '2']]],
   ')'
 ]

First: can this be parsed by LL(1)? (How about without the parens?)

Can we implement a python program here in class, using the ideas from the code I showed on Monday to generate these "full parse trees"?

Can we then use that write an FPE to scheme compiler in python? YES!

Here's the version I did last night, and what we did in class :

• parsing code - last night & today in class
  • recursive_descent.py
  • rec_desc_in_class.py
  • fpe : compiling to scheme

dickinson language

Here are some of your thoughts .

However, after further consideration, I think that this is not LL(1) :

f(x,y) = ...

because we won't be able to distinguish it from just f(x,y) without looking ahead further than one token.

Let's discuss ...

We did add some thoughts to that page in during our class discussion ... and will try to come to a consensus on Monday; I'll bring some proposals to class.