syntax semantics
Download
Skip this Video
Download Presentation
Syntax != Semantics

Loading in 2 Seconds...

play fullscreen
1 / 28

Syntax != Semantics - PowerPoint PPT Presentation


  • 129 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Syntax != Semantics' - york


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

slide7

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

slide16

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

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

slide22

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

ad