# Syntax != Semantics - PowerPoint PPT Presentation

1 / 28

Syntax != Semantics. Grammars. Help to. determine ??. Determine. Ambiguities. 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 am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Syntax != Semantics

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Grammars

Help to

determine ??

Determine

Ambiguities

IT 327

### 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

if (a > 2)

if (b > 1)

b++;

else

a++;

Dangling else

if (a > 2)

if (b > 1)

b++;

else

a++;

IT 327

### 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

### 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

### 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

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

### A grammar for Arithmetic Expressions

<exp> ::= <exp> + <exp> |

<exp> * <exp> |

( <exp> ) |

a | b | c

Example: ((a+b)*c)

IT 327

### 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

### 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

### 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

### 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

<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

### 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

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

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

### 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

IT 327

### 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

### 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

### 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

parse tree

abstract syntax tree

IT 327

### 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

### 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

### Operator Position

• infix:a + b

• prefix:+ a b

• postfix:a b +

IT 327

### 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

### Precedence Examples in C

a + b * c

a = b < c ? * p + b * c : 1 << d ()

a <= 0 || 100 <= a

IT 327

### 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