Syntax != Semantics

1. Syntax != Semantics Grammars Help to determine ?? Determine Ambiguities IT 327

2. Ambiguity in English I saw an airplane with a telescope. I saw a girl with her boyfriend. I saw a boy scout with a telescope on the mountain top. I saw a pretty girl with a telescope on the mountain top. IT 327

3. Ambiguity in Programming Languages if (a > 2) if (b > 1) b++; else a++; Dangling else if (a > 2) if (b > 1) b++; else a++; IT 327

4. Three “Equivalent” Grammars G1: <subexp> ::= <subexp> - <subexp> | a | b | c G2: <subexp> ::= <var> - <subexp> | <var><var> ::= a | b | c G3: <subexp> ::= <subexp> - <var> | <var><var> ::= a | b | c They are equivalent! (what does that mean?) IT 327

5. Parse a – b - c using G1 G1: <subexp> ::= <subexp> - <subexp> | a | b | c <subexp> <subexp> <subexp> - <subexp> <subexp> - <subexp> a <subexp> - <subexp> <subexp> - <subexp> c b c a b G1 is an ambiguous grammar IT 327

6. Left and Right Association rules Right associative rule: a-b-c-d = a–(b-(c-d)) Left associative rule: a-b-c-d = ((a–b)-c)-d IT 327

7. G3: <subexp> ::= <subexp> - <var> | <var><var> ::= a | b | c G2: <subexp> ::= <var> - <subexp> | <var><var> ::= a | b | c <subexp> <subexp> <subexp> - <var> <var> - <subexp> <subexp> - <var> c a <var> - <subexp> b <var> b <var> c a Right associative rule: a-b-c = a-(b-c) Left associative rule: a-b-c = (a-b)-c IT 327

8. A grammar for Arithmetic Expressions <exp> ::= <exp> + <exp> | <exp> * <exp> | ( <exp> ) | a | b | c Example: ((a+b)*c) IT 327

9. What is the meaning of a+b*c We prefer this Using left--most derivation <exp> <exp> <exp> + <exp> <exp> * <exp> c a <exp> * <exp> <exp> + <exp> b c a b Using right-most derivation doesn’t help IT 327

10. The problem is too much freedom <exp> <exp> Call this a term <exp> * <exp> <exp> + <exp> c And term does not generate exp directly <exp> + <exp> a <exp> * <exp> a b b c Solution: restricting <exp> from generating * directly. A term is an exp: a*bAn exp may not be a term: a+b <exp> ::= <term> <term> ::= <exp> <term> ::= (<exp> ) IT 327

11. An unambiguous grammar for Arithmetic Expressions <exp> <exp> ::= <term> + <exp> | <term> <term> ::= <fact> * <term> | <fact> <fact> ::=( <exp> ) | a | b | c <term> + <exp> <fact> <term> <fact> * <term> Example: a+b*c a <fact> b c IT 327

12. An unambiguous grammar for Arithmetic Expressions <exp> ::= <term> + <exp> | <term> <term> ::= <fact> * <term> | <fact> <fact> ::=( <exp> ) | a | b | c <exp> <term> + <exp> <fact> <term> + <exp> <term> a <fact> Example: a+b+c <fact> Right association b a+b+c = a+(b+c) c IT 327

13. <exp> Using ( and ) to alter the order <exp> ::= <term> + <exp> | <term> <term> ::= <fact> * <term> | <fact> <fact> ::=( <exp> ) | a | b | c <term> + <exp> <term> <fact> <fact> ( <exp> ) Example: (a+b)+c <term> + <exp> c a b IT 327

14. An unambiguous left associative grammar (?) for Arithmetic Exp. No such thing called left associative grammar <exp> A better way to say this: A grammar for left associative arithmetic exp. <exp> + <term> <exp> ::= <exp> + <term> | <term> <term> ::= <term> * <fact> | <fact> <fact> ::=( <exp> ) | a | b | c <exp> + <term> <fact> <term> <fact> c Example: a+b+c <fact> b a IT 327

15. Too much freedom to generate if statements from stmt Dangling else <stmt> ::= <if-stmt> | s1 | s2 <if-stmt> ::= if <expr> then <stmt> else <stmt> | if <expr> then <stmt> <expr> ::= e1 | e2 if e1 thenif e2 then s1 else s2 if (a > 2) if (b > 1) b++; else a++; if (a > 2) if (b > 1) b++; else a++; IT 327

16. if (a > 2) if (b > 1) b++; else a++; if (a > 2) if (b > 1) b++; else a++; Most languages: elsegoes withnearest then IT 327

17. Eliminating The Ambiguity Numbers of then and else are the same <stmt> ::= <if-stmt> | s1 | s2 <if-stmt> ::= if <expr> then <full-stmt> else <stmt> | if <expr> then <stmt> <expr> ::= e1 | e2 <full-stmt> ::= <full-if> | s1 | s2 <full-if> ::= if <expr> then <full-stmt> else <full-stmt> IT 327

18. A Parse Tree for if-stmt IT 327

19. Languages That Don’t Dangle Algol: then part can’t be another if (a block is allowed) Ada: if statement must be terminated with an end if IT 327

20. Options to deal with ambiguity • Rewrite grammar to eliminate ambiguity • Leave ambiguity but explain in accompanying text how things like associativity, precedence, and the dangling else should be parsed • Do both in separate grammars IT 327

21. Abstract Syntax Tree • Abbreviated version of the parse tree • Details are implementation-dependent • Usually, there is a node for every operation, with a subtree for every operand Most systems construct an AST instead IT 327

22. parse tree abstract syntax tree IT 327

23. Operators • Special symbols for frequently-used simple operations like addition, subtraction, multiplication and division • Usually predefined, but not always • Usually a single token, but not always IT 327

24. Operands • Operands are the inputs to an operator, like 1 and 2 in the expression 1+2 • Unary operators take one operand: -1 • Binary operators take two: 1+2 • Ternary operators take three: a?b:c IT 327

25. Operator Position • infix:a + b • prefix:+ a b • postfix:a b + IT 327

26. Operator Precedence The priority in In the competition of getting operands. Most languages put * at a higher precedence level than +. a+b*c = a+(b*c) (sign, as unary operators) + - ^ * / % + - := IT 327

27. Precedence Examples in C a + b * c a = b < c ? * p + b * c : 1 << d () a <= 0 || 100 <= a IT 327

28. Some conclusions from the textbook with (my view) • Grammars define syntax, and more(more?) • They define not just a set of legal programs, but the (a) parse tree for each program • The structure of a parse tree corresponds to the order (entity) in which different parts of the program are to be executed (as an entity) • Thus, grammars contribute (a little) to the definition of semantics IT 327