Syntax semantics
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

Syntax != Semantics PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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

Presentation Transcript


Syntax semantics

Syntax != Semantics

Grammars

Help to

determine ??

Determine

Ambiguities

IT 327


Ambiguity in english

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


Ambiguity in programming languages

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


Three equivalent grammars

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

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

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


Syntax semantics

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

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

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

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

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 expressions1

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


Using and to alter the order

<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

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


Dangling else

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


Syntax semantics

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

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


A parse tree for if stmt

A Parse Tree for if-stmt

IT 327


Languages that don t dangle

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

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

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


Syntax semantics

parse tree

abstract syntax tree

IT 327


Operators

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

  • 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

Operator Position

  • infix:a + b

  • prefix:+ a b

  • postfix:a b +

IT 327


Operator precedence

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

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

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


  • Login