1. Grammars Examples and Issues

2. Examples from Last Lecture • a+b • a b+ • a*bc* • First draw a state diagram • Then create a rule for each transition

3. a+b a a b 2 3 1 <1> -> a <2> <2> -> a <2> <2> -> b <3> <3> -> e <1> -> a <2> <2> -> a <2> | b or

4. a b+ b a b 2 3 1 <1> -> a <2> <2> -> b <3> <3> -> b <3> <3> -> e <1> -> a <2> <2> -> b <3> <3> -> b <3> | e or (e represents an empty string … done)

5. a*bc* c a b 2 1 <1> -> a <1> <1> -> b <2> <2> -> c <2> <2> -> e <1> -> a <1> | b <2> <2> -> b <2> | e or (e represents an empty string … done)

6. What does this have to do with programming languages? • Text processing is common in applications • Generalizing formats make processing more complex • html and xml are examples <title> Grammars and Programming </title> • Compilers need to process strings

7. State Diagram

8. Lexical Analysis (cont.) Implementation (assume initialization): int lex() { getChar(); switch (charClass) { case LETTER: addChar(); getChar(); while (charClass == LETTER || charClass == DIGIT) { addChar(); getChar(); } return lookup(lexeme); break; …

9. Summary • Regular expressions, regular grammars, state machines are all related • They represent tools to aid in the processing of text • Coding structure (see the addChar/getChar calls in the previous example) follows the state machine structure.

10. Could you write a state machine to recognize html titles?

11. Could you write a program to recognize html titles?

12. Other issues? • Compilers start with derived strings. • Then try to “reverse engineer” the structure/derivation associated with the program. • If the grammar is too simple, there are multiple interpretations …. • AMBIGUITY! • First lets look at a Context Free Grammar

13. An Example Grammar <program>  <stmts> <stmts>  <stmt> | <stmt> ; <stmts> <stmt>  <var> = <expr> <var>  a | b | c | d <expr>  <term> + <term> | <term> - <term> <term>  <var> | const

14. An Example Derivation <program> => <stmts> => <stmt> => <var> = <expr> => a = <expr> => a = <term> + <term> => a = <var> + <term> => a = b + <term> => a = b + const

15. Parse Tree • A hierarchical representation of a derivation <program> <stmts> <stmt> <var> = <expr> a <term> + <term> <var> const b

16. Ambiguity in Grammars • A grammar is ambiguous if and only if it generates a sentential form that has two or more distinct parse trees

17. An Ambiguous Expression Grammar <expr>  <expr> <op> <expr> | const <op>  / | - <expr> <expr> <expr> <op> <expr> <expr> <op> <op> <expr> <expr> <op> <expr> <expr> <op> <expr> const - const / const const - const / const

18. An Unambiguous Expression Grammar • If we use the parse tree to indicate precedence levels of the operators, we cannot have ambiguity <expr>  <expr> - <term> | <term> <term>  <term> / const| const <expr> <expr> - <term> <term> <term> / const const const

19. Associativity of Operators • Operator associativity can also be indicated by a grammar <expr> -> <expr> + <expr> | const (ambiguous) <expr> -> <expr> + const | const (unambiguous) <expr> <expr> <expr> + const <expr> + const const

20. Awkward Appearance of Grammars • Not for you • For compilers to have unambiguous interpretation • As with string processing, provides the basis of program structure for writing compilers.