1

CS 403 - Programming Languages

Class 05September 7, 2000

CS 403, Class 05 Slide # 2

Today’s Agenda

Announcement: Collecting samples of student work for CSAB accreditation visit next year.Chapter 3 Finish Syntax Semantics

Assignment: Read chapter 4 for Tuesday.

CS 403, Class 05 Slide # 3

Study Recommendations

You should be able to do the exercises on pages 151, 152 & 153.

CS 403, Class 05 Slide # 4

Reading Quiz

Give the phrase for these acronyms1. BNF2. CFG

Draw a line, confer with mates, correct your answers if necessary.Turn them in.

CS 403, Class 05 Slide # 5

Chapter 3: Syntax & Semantics

Syntax: the form or structure of the expressions statements, and program units

Semantics: the meaning of the expressions, statements, and program units

CS 403, Class 05 Slide # 6

Ambiguous Grammars

A grammar is ambiguous iff (if and only if) it generates a sentential form that has two or more distinct parse trees.A simple example:

<expr> <expr> <op> <expr> | const

<op> / | -Can you draw two parse trees for this expression?

const - const / const

CS 403, Class 05 Slide # 7

Two Parse Trees: Ambiguous!

<expr> <expr>

<expr> <op> <expr> <expr> <op> <expr>

<expr><op><expr> <expr><op><expr>

const - const / const const - const / const

Expression: const - const / const

Operator precedence?

CS 403, Class 05 Slide # 8

Operator Precedence (one way)

If we use the parse tree to indicate precedence levels of the operators, we cannot have ambiguity

An unambiguous expression grammar:

<expr> <expr> - <term> | <term>

<term> <term> / const | const

CS 403, Class 05 Slide # 9

<expr>

<expr> - <term>

<term> <term> / const

const const

Operator PrecedenceAn unambiguous expression grammar:

<expr> <expr> - <term> | <term>

<term> <term> / const | const

CS 403, Class 05 Slide # 10

Grammar for Precedence

<expr> <expr> - <term>

<term> - <term>

const - <term>

const - <term> / const

const - const / const

CS 403, Class 05 Slide # 11

Extended BNF

1. Optional parts are placed in brackets ([])

<proc_call> -> ident [ ( <expr_list>)]

2. Put alternative parts of RHSs in parentheses and separate them with vertical bars

<term> -> <term> (+ | -) const

3. Put repetitions (0 or more) in braces ({}) <ident> -> letter {letter | digit}

CS 403, Class 05 Slide # 12

BNF <--> EBNF

BNF: <expr> -> <expr> + <term> | <expr> - <term>

| <term>

<term> -> <term> * <factor>

| <term> / <factor>

| <factor>

EBNF:<expr> -> <term> {(+ | -) <term>}

<term> -> <factor> {(* | /) <factor>}

CS 403, Class 05 Slide # 13

Syntax Graphs

Put the terminals in circles or ellipses and put the nonterminals in rectangles; connect with lines with arrowheads: e.g., Pascal type declarations

type_identifier

identifier

constant constant

(

,

)

..

CS 403, Class 05 Slide # 14

Recursive Descent Parsing

Parsing is the process of tracing or constructing a parse tree for a given input string.

Parsers usually do not analyze lexemes; that is done by a lexical analyzer, which is called by the parser.

A recursive descent parser traces out a parse tree in top-down order; it is a top-down parser.

CS 403, Class 05 Slide # 15

Recursive Descent Parsing

Each nonterminal in the grammar has a subprogram associated with it; the subprogram parses all sentential forms that the nonterminal can generate.

The recursive descent parsing subprograms are built directly from the grammar rules.

Recursive descent parsers, like other top-down parsers, cannot be built from left-recursive grammars.

CS 403, Class 05 Slide # 16

Recursive Descent Parsing

Example: For the grammar: <term> -> <factor> {(* | /) <factor>}

We could use the following recursive descent parsing subprogram (this one is written in C)

void term() { factor(); /* parse the first factor*/ while (next_token == asterisk_code || next_token == slash_code) { lexical(); /* get next token */ factor(); /* parse the next factor */ } }

CS 403, Class 05 Slide # 17

Static semantics

(Have nothing to do with “meaning”)

Categories:

1. Context-free but cumbersome (e.g. type checking)

2. Noncontext-free (e.g. variables must be declared before they are used)

CS 403, Class 05 Slide # 18

Attribute Grammars (AGs)

CFGs cannot describe all of the syntax of programming languages

Additions to CFGs to carry some semantic info along through parse trees

Primary value of AGs:

1. Static semantics specification

2. Compiler design (static semantics checking)

CS 403, Class 05 Slide # 19

Attribute GrammarsDefinition: An attribute grammar is a CFG G = (S, N, T, P)with the following additions:

1. For each grammar symbol x there is a set A(x) of attribute values.

2. Each rule has a set of functions that define certain attributes of the nonterminals in the rule.

3. Each rule has a (possibly empty) set of predicates to check for attribute consistency.

CS 403, Class 05 Slide # 20

AG Example 1

Let X0 -> X1 ... Xn be a rule.

Functions of the form S(X0) = f(A(X1), ... A(Xn)) define synthesized attributes.

Pass information up the parse tree.

Functions of the form I(Xj) = f(A(X0), ... , A(Xn)), for i <= j <= n, define inherited attributes.

Pass information down the parse tree.

Initially, there are intrinsic attributes on the leaves (i.e.: data type).

CS 403, Class 05 Slide # 21

AG Example 1 (2)

Example: expressions of the form id + id id's can be either int_type or real_type types of the two id's must be the same type of the expression must match its

expected type

CS 403, Class 05 Slide # 22

AG Example 2 (3)

BNF:

<expr> -> <var> + <var> <var> -> id

Attributes: actual_type - synthesized for <var> and <expr> expected_type - inherited for <expr>

CS 403, Class 05 Slide # 23

Attribute Example B (1)

1. Syntax rule: <expr> -> <var>[1] + <var>[2]

Semantic rules:

<var>[1].env <expr>.env

<var>[2].env <expr>.env

<expr>.actual_type <var>[1].actual_type

Predicate:

<var>[1].actual_type = <var>[2].actual_type

<expr>.expected_type = <expr>.actual_type

CS 403, Class 05 Slide # 24

Attribute Example B (2)

2. Syntax rule: <var> -> id

Semantic rule:

<var>.actual_type <- lookup (id, <var>.env)