View
12
Download
0
Category
Preview:
Citation preview
1
1Organization of Programming Languages-Cheng (Fall 2005)
Implementation, Syntax, andSemantics
2Organization of Programming Languages-Cheng (Fall 2005)
Implementation Methods
Compilation Translate high-level program to machine code Slow translation Fast execution
CompilerSource Program
Target Program
Target ProgramInput Output
3Organization of Programming Languages-Cheng (Fall 2005)
CompilationProcess
Compiler
2
4Organization of Programming Languages-Cheng (Fall 2005)
Implementation Methods
Pure interpretation No translation Slow execution Becoming rare
Interpreter
Source Program
Output
Input
5Organization of Programming Languages-Cheng (Fall 2005)
Implementation Methods
Hybrid implementation systems Small translation cost Medium execution speed
Virtual Machine
IntermediateProgram
Output
Input
TranslatorSource Program
IntermediateProgram
6Organization of Programming Languages-Cheng (Fall 2005)
HybridImplementationSystem
Translator
3
7Organization of Programming Languages-Cheng (Fall 2005)
Programming Environments
The collection of tools used in softwaredevelopment
UNIX An older operating system and tool collection
Borland JBuilder An integrated development environment for
Java Microsoft Visual Studio.NET
A large, complex visual environment Used to program in C#, Visual BASIC.NET,
Jscript, J#, or C++
8Organization of Programming Languages-Cheng (Fall 2005)
Describing Syntax
Lexemes: lowest-level syntactic units
Tokens: categories of lexemes
sum = x + 2 – 3
Lexemes: sum, =, x, +, 2, -, 3
Tokens: identifier, equal_sign, plus_op, integer_literal, minus_op
9Organization of Programming Languages-Cheng (Fall 2005)
Formal Method for Describing Syntax
Backus-Naur form (BNF) Also equivalent to context-free grammars, developed by Noam
Choamsky (a linguist) BNF is a meta-language
a language used to describe another language Consists of a collection of rules (or productions) Example of a rule:
<assign> → < var > = < expression >LHS: the abstraction being definedRHS: contains a mixture of tokens, lexemes, and references to other
abstractions Abstractions are called non-terminal symbols Lexemes and tokens are called terminal symbols Also contains a special non-terminal symbol called the start
symbol
4
10Organization of Programming Languages-Cheng (Fall 2005)
Example of a grammar in BNF
<program> → begin <stmt_list> end<stmt_list> → <stmt> | <stmt>; <stmt_list><stmt> → <var> = <expression><var> → A | B | C | D<expression> → <var> + <var> | <var> - <var> |
<var>
11Organization of Programming Languages-Cheng (Fall 2005)
Derivation
The process of generating a sentence
begin A = B – C end
Derivation: <program> (start symbol)
=> begin <stmt_list> end => begin <stmt> end => begin <var> = <expression> end => begin A = <expression> end => begin A = <var> - <var> end => begin A = B - <var> end => begin A = B - C end
12Organization of Programming Languages-Cheng (Fall 2005)
BNF
Leftmost derivation: the replaced non-terminal is always the
leftmost non-terminal Rightmost derivation
the replaced non-terminal is always therightmost non-terminal
Sentential forms Each string in the derivation, including
<program>
5
13Organization of Programming Languages-Cheng (Fall 2005)
Derivation
begin A = B + C; B = C end
Rightmost: <program> (start symbol) => begin <stmt_list> end => begin <stmt>; <stmt_list> end => begin <stmt>; <stmt> end => begin <stmt>; <var> = <expression> end => begin <stmt>; <var> = <var> end => begin <stmt>; <var> = C end => begin <stmt>; B = C end=> begin <var> = <expression>; B = C end=> begin <var> = <var> + <var>; B = C end=> begin <var> = <var> + C; B = C end=> begin <var> = B + C; B = C end => begin A = B + C; B = C end
14Organization of Programming Languages-Cheng (Fall 2005)
Parse Tree
A hierarchical structure that shows the derivationprocess
Example:<assign> → <id> = <expr><id> → A | B | C | D<expr> → <id> + <expr>
| <id> - <expr> | ( <expr> ) | <id>
15Organization of Programming Languages-Cheng (Fall 2005)
Parse Tree
A = B * (A + C)
<assign>Þ <id> = <expr>Þ A = <expr>Þ A = <id> * <expr>Þ A = B * <expr>Þ A = B * ( <expr> )Þ A = B * ( <id> + <expr> )Þ A = B * ( A + <expr> )Þ A = B * ( A + <id> )Þ A = B * ( A + C )
6
16Organization of Programming Languages-Cheng (Fall 2005)
Ambiguous Grammar
A grammar that generates a sentence for which there aretwo or more distinct parse trees is said to be ambiguous
Example:<assign> → <id> + <expr><id> → A | B | C | D<expr> → <expr> + <expr>
| <expr> * <expr> | ( <expr> ) | <id>
Draw two different parse trees forA = B + C * A
17Organization of Programming Languages-Cheng (Fall 2005)
Ambiguous Grammar
18Organization of Programming Languages-Cheng (Fall 2005)
Ambiguous Grammar
Is the following grammar ambiguous?
<if_stmt> → if <logic_expr> then <stmt> | if <logic_expr> then <stmt> else
<stmt>
7
19Organization of Programming Languages-Cheng (Fall 2005)
Operator Precedence
A = B + C * A
How to force “*” to have higher precedence over“+”?
Answer: add more non-terminal symbols
Observe that higher precedent operator resideat “deeper” levels of the trees
20Organization of Programming Languages-Cheng (Fall 2005)
Operator Precedence
A = B + C * A
Before:<assign> → <id> + <expr><id> → A | B | C | D<expr> → <expr> + <expr>
| <expr> * <expr> | ( <expr> ) | <id>
After:<assign> → <id> + <expr><id> → A | B | C | D<expr> → <expr> + <term>
| <term><term> → <term> * <factor>
| <factor><factor> → ( <expr> )
| <id>
21Organization of Programming Languages-Cheng (Fall 2005)
Operator Precedence
A = B + C * A
8
22Organization of Programming Languages-Cheng (Fall 2005)
Associativity of Operators
A = B + C – D * F / G Left-associative
Operators of the same precedence evaluatedfrom left to right
C++/Java: +, -, *, /, % Right-associative
Operators of the same precedence evaluatedfrom right to left
C++/Java: unary -, unary +, ! (logicalnegation),~ (bitwise complement)
How to enforce operator associativity using BNF?
23Organization of Programming Languages-Cheng (Fall 2005)
Associativity of Operators
<assign> → <id> = <expr>
<id> → A | B | C | D
<expr> → <expr> + <term>
| <term>
<term> → <term> * <factor>
| <factor>
<factor> → ( <expr> )
| <id>
Left-associativeLeft-recursive rule
24Organization of Programming Languages-Cheng (Fall 2005)
Associativity of Operators
<assign> → <id> = <factor>
<factor> → <exp> ^ <factor>
| <exp>
<exp> → (<expr>) | <id>
<id> → A | B | C | D
Right-recursive rule
Exercise: Draw the parse tree for A = B^C^D(use leftmost derivation)
9
25Organization of Programming Languages-Cheng (Fall 2005)
Extended BNF
BNF rules may grow unwieldy for complexlanguages
Extended BNF Provide extensions to “abbreviate” the rules
into much simpler forms Does not enhance descriptive power of BNF Increase readability and writability
26Organization of Programming Languages-Cheng (Fall 2005)
Extended BNF
Optional parts are placed in brackets ([ ]) <select_stmt> → if ( <expr> ) <stmt> [ else <stmt> ]
Put alternative parts of RHSs in parenthesesand separate them with vertical bars
<term> → <term> (+ | -) const
Put repetitions (0 or more) in braces ({ }) <id_list> → <id> { , <id> }
27Organization of Programming Languages-Cheng (Fall 2005)
Extended BNF (Example)
BNF:<expr> → <expr> + <term>
| <expr> - <term> | <term>
<term> → <term> * <factor> | <term> / <factor> | <factor>
<factor> → <exp> ^ <factor> | <exp>
<exp> → ( <expr> ) | <id>
EBNF:<expr> → <term> {(+|-)
<term>}
<term>→<factor>{(*|/)<factor>}
<factor> →<exp>{^ <exp>}
<exp> → ( <expr> ) | <id>
10
28Organization of Programming Languages-Cheng (Fall 2005)
Compilation
29Organization of Programming Languages-Cheng (Fall 2005)
Lexical Analyzer
A pattern matcher for character strings The “front-end” for the parser Identifies substrings of the source program that belong
together => lexemes Lexemes match a character pattern, which is
associated with a lexical category called a token Example: sum = B –5;
Lexeme Tokensum ID (identifier)= ASSIGN_OPB ID- SUBTRACT_OP5 INT_LIT (integer literal); SEMICOLON
30Organization of Programming Languages-Cheng (Fall 2005)
Lexical Analyzer
Functions: Extract lexemes from a given input string and produce
the corresponding tokens, while skipping commentsand blanks
Insert lexemes for user-defined names into symboltable, which is used by later phases of the compiler
Detect syntactic errors in tokens and report sucherrors to user
How to build a lexical analyzer? Create a state transition diagram first
A state diagram is a directed graph Nodes are labeled with state names
One of the nodes is designated as the start node Arcs are labeled with input characters that cause the
transitions
11
31Organization of Programming Languages-Cheng (Fall 2005)
State Diagram (Example)
Letter → A | B | C |…| Z | a | b | … | zDigit → 0 | 1 | 2 | … | 9id → Letter{(Letter|Digit)}int → Digit{Digit}
main () {
int sum = 0, B = 4;
sum = B - 5;
}
32Organization of Programming Languages-Cheng (Fall 2005)
Lexical Analyzer
Need to distinguish reserved words from identifiers
e.g., reserved words: main and int identifiers: sum and B
Use a table lookup to determine whether a possibleidentifier is in fact a reserved word To determine
whether id isa reserved word
33Organization of Programming Languages-Cheng (Fall 2005)
Lexical Analyzer
Useful subprograms in the lexical analyzer: lookup
determines whether the string in lexeme is areserved word (returns a code)
getChar reads the next character of input string, puts it in a
global variable called nextChar, determines itscharacter class (letter, digit, etc.) and puts theclass in charClass
addChar Appends nextChar to the current lexeme
12
34Organization of Programming Languages-Cheng (Fall 2005)
Lexical Analyzerint lex() {
switch (charClass) { case LETTER: addChar();
getChar(); while (charClass == LETTER || charClass == DIGIT) { addChar(); getChar(); } return lookup(lexeme); break; case DIGIT: addChar(); getChar(); while (charClass == DIGIT) { addChar(); getChar(); } return INT_LIT; break; } /* End of switch */} /* End of function lex */
35Organization of Programming Languages-Cheng (Fall 2005)
Parsers (Syntax Analyzers)
Goals of a parser: Find all syntax errors Produce parse trees for input program
Two categories of parsers: Top down
produces the parse tree, beginning at the rootUses leftmost derivation
Bottom upproduces the parse tree, beginning at the leavesUses the reverse of a rightmost derivation
36Organization of Programming Languages-Cheng (Fall 2005)
Recursive Descent Parser
A top-down parser implementation Consists of a collection of subprograms
A recursive descent parser has a subprogramfor each non-terminal symbol
If there are multiple RHS for a given nonterminal, parser must make a decision which RHS to
apply first A → x… | y…. | z…. | … The correct RHS is chosen on the basis of the
next token of input (the lookahead)
13
37Organization of Programming Languages-Cheng (Fall 2005)
Recursive Descent Parser
<expr> → <term> {(+|-) <term>}<term> → <factor> {(*|/) <factor>}<factor> → id | ( <expr> )
void expr() {term();
while ( nextToken ==PLUS_CODE || nextToken == MINUS_CODE ) { lex(); term(); }}
lex() is the lexical analyzer function. It gets the next lexeme and puts itstoken code in the global variable nextToken
All subprograms are written with the convention that each one leaves thenext token of input in nextToken
Parser uses leftmost derivation
38Organization of Programming Languages-Cheng (Fall 2005)
Recursive Descent Parser
<expr> → <term> {(+|-) <term>}<term> → <factor> {(*|/) <factor>}<factor> → id | ( <expr> )
void factor() { /* Determine which RHS */if (nextToken == ID_CODE)
lex();else if (nextToken ==LEFT_PAREN_CODE) {
lex(); expr(); if (nextToken ==
RIGHT_PAREN_CODE) lex(); else error();
}else
error(); /* Neither RHS matches */ }
39Organization of Programming Languages-Cheng (Fall 2005)
Recursive Descent Parser
Problem with left recursion A → A + B (direct left recursion) A → B c D (indirect left recursion)
B → A b A grammar can be modified to remove left recursion
Inability to determine the correct RHS on the basis of onetoken of lookahead Example: A → aC | Bd
B → ac C → c
14
40Organization of Programming Languages-Cheng (Fall 2005)
LR Parsing
LR Parsers are almost always table-driven Uses a big loop to repeatedly inspect 2-dimen
table to find out what action to take Table is indexed by current input token and
current state Stack contains record of what has been seen SO
FAR (not what is expected/predicted to see infuture)
PDA: Push down automata: State diagram looks just like a DFA state diagram Arcs labeled with <input symbol, top-of-stack
symbol>
41Organization of Programming Languages-Cheng (Fall 2005)
PDAs
LR PDA: is a recognizer Builds a parse tree bottom up States keep track of which productions we
“might” be in the middle of.
42Organization of Programming Languages-Cheng (Fall 2005)
Example
<pgm> -> <stmt list> $$
<stmt list>-> <stmt list> <stmt> |
<stmt>
<stmt> -> id := <expr> |
read id | write <expr>
<expr> -> <term> |
<expr> <add op> <term>
<term> -> <factor> |
<term> <mult op> <factor>
<factor> -> ( <expr> ) | id |
literal
<add op> -> + | -
<mult op> -> * | /
read A
read B
sum := A + B
write sum
write sum / 2
15
43Organization of Programming Languages-Cheng (Fall 2005)
STOP
44Organization of Programming Languages-Cheng (Fall 2005)
Static Semantics
BNF cannot describe all of the syntax of PLs Examples:
All variables must be declared before they are referenced The end of an Ada subprogram is followed by a name, that name
must match the name of the subprogramProcedure Proc_example (P: in Object) is begin
…. end Proc_example
Static semantics Rules that further constrain syntactically correct programs In most cases, related to the type constraints of a language Static semantics are verified before program execution (unlike
dynamic semantics, which describes the effect of executing theprogram)
BNF cannot describe static semantics
45Organization of Programming Languages-Cheng (Fall 2005)
Attribute Grammars (Knuth, 1968)
A BNF grammar with the following additions: For each symbol x there is a set of attribute values, A(x)
A(X) = S(X) ∪ I(X) S(X): synthesized attributes
– used to pass semantic information up a parse tree I(X): inherited attributes
– used to pass semantic information down a parse tree Each grammar rule has a set of functions that define
certain attributes of the nonterminals in the rule Rule: X0 → X1 … Xj … Xn
S(X0) = f (A(X1), …, A(Xn))I(Xj) = f (A(X0), …, A(Xj-1))
A (possibly empty) set of predicate functions to checkwhether static semantics are violated Example: S(Xj ) = I (Xj ) ?
16
46Organization of Programming Languages-Cheng (Fall 2005)
Attribute Grammars (Example)
Procedure Proc_example (P: in Object) is begin
…. end Proc_example
Syntax rule:<Proc_def> → Procedure <proc_name>[1]
<proc_body>end <proc_name>[2]
Semantic rule:<proc_name>[1].string = <proc_name>[2].string
attribute
47Organization of Programming Languages-Cheng (Fall 2005)
Attribute Grammars (Example)
Expressions of the form <var> + <var> var's can be either int_type or real_type If both var’s are int, result of expr is int If at least one of the var’s is real, result of expr is real
BNF<assign> → <var> = <expr> (Rule 1)<expr> → <var> + <var> (Rule 2)
| <var> (Rule 3)<var> → A | B | C (Rule 4)
Attributes for non-terminal symbols <var> and <expr> actual_type - synthesized attribute for <var> and <expr> expected_type - inherited attribute for <expr>
48Organization of Programming Languages-Cheng (Fall 2005)
Attribute Grammars (Example)
Syntax rule: <assign> → <var> = <expr>Semantic rule: <expr>.expected_type ← <var>.actual_type
Syntax rule: <expr> → <var>[2] + <var>[3]Semantic rule:
<expr>.actual_type ← if ( <var>[2].actual_type = int) and<var>[3].actual_type = int)then intelse real
end ifPredicate: <expr>.actual_type = <expr>.expected_type
Syntax rule: <expr> → <var>Semantic rule:
<expr>.actual_type ← <var>.actual_type Predicate: <expr>.actual_type = <expr>.expected_type
Syntax rule: <var> → A | B | CSemantic rule:
<var>.actual_type ← lookup(<var>.string)
Note: Lookup function looks up a given variable name in the symbol tableand returns the variable’s type
17
49Organization of Programming Languages-Cheng (Fall 2005)
Parse Trees for Attribute Grammars
A = A + B <assign>
<expr>
<var> var[2] var[3]
A = A + BHow are attribute values computed?1. If all attributes were inherited, the tree could be decorated in top-down
order.2. If all attributes were synthesized, the tree could be decorated in bottom-
up order.3. If both kinds of attributes are present, some combination of top-down
and bottom-up must be used.
50Organization of Programming Languages-Cheng (Fall 2005)
Parse Trees for Attribute Grammars
<assign> → <var> = <expr><expr>.expected_type ←<var>.actual_type
<expr> → <var>[2] + <var>[3]<expr>.actual_type ←
if ( <var>[2].actual_type = int) and
<var>[3].actual_type = int) then int else realend if
Predicate: <expr>.actual_type = <expr>.expected_type
<expr> → <var><expr>.actual_type ← <var>.actual_type Predicate: <expr>.actual_type =<expr>.expected_type
<var> → A | B | C<var>.actual_type ←lookup(<var>.string)
<var>.actual_type ← lookup(A) (Rule 4)
<expr>.expected_type ←<var>.actual_type
(Rule 1)
<var>[2].actual_type ← lookup(A) (Rule 4)
<var>[3].actual_type ← lookup(B) (Rule 4)
<expr>.actual_type ← either int orreal(Rule 2)
<expr>.expected_type =<expr>.actual_type is either TRUE orFALSE (Rule 2)
A = A + B
51Organization of Programming Languages-Cheng (Fall 2005)
Parse Trees for Attribute Grammars
1
2
3 3
4 4
5Predicate test
18
52Organization of Programming Languages-Cheng (Fall 2005)
Attribute Grammar Implementation
Determining attribute evaluation order is a complexproblem, requiring the construction of a dependencygraph to show all attribute dependencies
Difficulties in implementation The large number of attributes and semantic rules
required make such grammars difficult to write and read Attribute values for large parse trees are costly to
evaluate
Less formal attribute grammars are used by compilerwriters to check static semantic rules
53Organization of Programming Languages-Cheng (Fall 2005)
Describing (Dynamic) Semantics
<for_stmt> → for (<expr1>; <expr2>; <expr3>)<assign_stmt> → <var> = <expr>;
What is the meaning of each statement? dynamic semantics
How do we formally describe the dynamicsemantics?
54Organization of Programming Languages-Cheng (Fall 2005)
Describing (Dynamic) Semantics
There is no single widely acceptable notation orformalism for describing dynamic semantics
Three formal methods: Operational Semantics Axiomatic Semantics Denotational Semantics
19
55Organization of Programming Languages-Cheng (Fall 2005)
Operational Semantics
Describe the meaning of a program by executingits statements on a machine, either simulated oractual. The change in the state of the machine(memory, registers, etc.) defines the meaning ofthe statement.
Execute Statement
Initial State:
(i1,v1), (i2,v2), …
Final State:
(i1,v1’), (i2,v2’), …
56Organization of Programming Languages-Cheng (Fall 2005)
Operational Semantics
To use operational semantics for a high-levellanguage, a virtual machine in needed. A hardware pure interpreter would be too
expensive A software pure interpreter also has problems:
1. The detailed characteristics of the particularcomputer would make actions difficult to understand
2. Such a semantic definition would bemachine- dependent.
57Organization of Programming Languages-Cheng (Fall 2005)
Operational Semantics
Approach: use a complete computer simulationBuild a translator (translates source code to
the machine code of an idealized computer)Build a simulator for the idealized computer
Example:C Statement: Operational Semantics:for (expr1; expr2; expr3) { expr1;
… loop: if expr2 = 0 goto out} …
expr3; goto loopout: …
20
58Organization of Programming Languages-Cheng (Fall 2005)
Operational Semantics
Valid statements for the idealized computer:iden = variden = iden + 1iden = iden – 1goto labelif var relop var goto label
Evaluation of Operational Semantics: Good if used informally (language manuals,
etc.) Extremely complex if used formally (e.g., VDL)
59Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics
Based on formal logic (first order predicate calculus)
Approach: Each statement is preceded and followed by a logical
expression that specifies constraints on programvariables
The logical expressions are called predicates or assertions
Define axioms or inference rules for each statementtype in the language
to allow transformations of expressions to other expressions
60Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics
{P} A = B + 1 {Q}
where P: precondition Q: postcondition
Precondition: an assertion before a statement that statesthe relationships and constraints among variables that aretrue at that point in execution
Postcondition: an assertion following a statement A weakest precondition is the least restrictive precondition
that will guarantee the postcondition Example: A = B + 1 {A > 1}
Postcondition: A > 1 One possible precondition: {B > 10} Weakest precondition: {B > 0}
21
61Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics
Program proof process: The postcondition for the whole program is the desired results. Work back through the program to the first statement. If the precondition on the first statement is the same as the
program spec, the program is correct. An axiom for assignment statements
{P} x = E {Q}
Axiom: P = Qx → E (P is computed with all instances of x replaced by E)
Example: a = b / 2 – 1 {a < 10} Weakest precondition: b/2 – 1 < 10 => b < 22 Axiomatic Semantics for assignment:
{Qx → E } x = E {Q}
62Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics
Inference rule for Sequences:{P1} S1 {P2}, {P2} S2 {P3}
{P1} S1; S2 {P3}
Example:Y = 3 * X + 1; X = Y + 3; {X < 10}
Precondition for second statement: {Y < 7} Precondition for first statement: {X < 2}
{X < 2} Y = 3 * X + 1; X = Y + 3; {X < 10}
63Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics: Axioms
An inference rule for logical pretest loops
{P} while B do S end {Q}
where I is the loop invariant (the inductive hypothesis)
B)}(not and {I S do B while{I}
{I} S B) and (I
22
64Organization of Programming Languages-Cheng (Fall 2005)
Axiomatic Semantics: Axioms
Characteristics of the loop invariant: I must meetthe following conditions: P => I -- the loop invariant must be true initially
{I} B {I} -- evaluation of the Boolean must not change the validity ofI
{I and B} S {I} -- I is not changed by executing the body of theloop
(I and (not B)) => Q -- if I is true and B is false, is implied
The loop terminates
65Organization of Programming Languages-Cheng (Fall 2005)
Loop Invariant
The loop invariant I is a weakened version of theloop postcondition, and it is also a precondition.
I must be weak enough to be satisfied prior to thebeginning of the loop, but when combined withthe loop exit condition, it must be strong enoughto force the truth of the postcondition
66Organization of Programming Languages-Cheng (Fall 2005)
Evaluation of Axiomatic Semantics
Developing axioms or inference rules for all of thestatements in a language is difficult
Utility: It is a good tool for correctness proofs, and an excellent framework for reasoning about
programs, it is not as useful for language users and
compiler writers Its usefulness in describing the meaning of a
programming language is limited for languageusers or compiler writers
23
67Organization of Programming Languages-Cheng (Fall 2005)
Denotational Semantics
Based on recursive function theory
The most abstract semantics description method
Originally developed by Scott and Strachey (1970)
68Organization of Programming Languages-Cheng (Fall 2005)
Denotational Semantics (cont’d)
The process of building a denotationalspecification for a language Define amathematical object for each language entity Define a function that maps instances of the
language entities onto instances of thecorresponding mathematical objects
The meaning of language constructs are definedby only the values of the program's variables
69Organization of Programming Languages-Cheng (Fall 2005)
Denotation vs Operational Semantics
In operational semantics, the state changes aredefined by coded algorithms
In denotational semantics, the state changesare defined by rigorous mathematical functions
24
70Organization of Programming Languages-Cheng (Fall 2005)
Denotational Sem.: Program State
The state of a program is the values of all itscurrent variables
s = {<i1, v1>, <i2, v2>, …, <in, vn>}
Let VARMAP be a function that, when given avariable name and a state, returns the currentvalue of the variable
VARMAP(ij, s) = vj
71Organization of Programming Languages-Cheng (Fall 2005)
Denotational Semantics
Based on recursive function theory
The meaning of language constructs are defined by thevalues of the program's variables
The process of building a denotational specification for alanguage: Define a mathematical object for each language entity Define a function that maps instances of the language
entities onto instances of the correspondingmathematical objects
72Organization of Programming Languages-Cheng (Fall 2005)
Denotational Semantics
Decimal Numbers The following denotational semantics description maps decimal
numbers as strings of symbols into numeric values Syntax rule:
<dec_num> → 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | <dec_num> (0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9)
Denotational Semantics:Mdec('0') = 0, Mdec ('1') = 1, …, Mdec ('9') = 9Mdec (<dec_num> '0') = 10 * Mdec (<dec_num>)Mdec (<dec_num> '1’) = 10 * Mdec (<dec_num>) + 1
… Mdec (<dec_num> '9') = 10 * Mdec (<dec_num>) + 9
Note: Mdec is a semantic function that maps syntactic objects to a set of non-negative decimal integer values
25
73Organization of Programming Languages-Cheng (Fall 2005)
Expressions
Map expressions onto Z ∪ {error} We assume expressions are decimal numbers,
variables, or binary expressions having onearithmetic operator and two operands, each ofwhich can be an expression
74Organization of Programming Languages-Cheng (Fall 2005)
3.5 Semantics (cont.)
Me(<expr>, s) Δ= case <expr> of <dec_num> => Mdec(<dec_num>, s) <var> => if VARMAP(<var>, s) == undef then error else VARMAP(<var>, s) <binary_expr> => if (Me(<binary_expr>.<left_expr>, s) == undef OR Me(<binary_expr>.<right_expr>, s) = undef) then error
else if (<binary_expr>.<operator> == ‘+’ then Me(<binary_expr>.<left_expr>, s) + Me(<binary_expr>.<right_expr>, s) else Me(<binary_expr>.<left_expr>, s) * Me(<binary_expr>.<right_expr>, s)...
75Organization of Programming Languages-Cheng (Fall 2005)
Assignment Statements
Maps state sets to state sets
Ma(x := E, s) Δ= if Me(E, s) == error then error else s’ =
{<i1’,v1’>,<i2’,v2’>,...,<in’,vn’>}, where for j = 1, 2, ..., n, vj’ = VARMAP(ij, s) if ij <> x = Me(E, s) if ij == x
26
76Organization of Programming Languages-Cheng (Fall 2005)
Logical Pretest Loops
Maps state sets to state sets
Ml(while B do L, s) Δ= if Mb(B, s) == undef
then error
else if Mb(B, s) == false
then s
else if Msl(L, s) == error
then error
else Ml(while B do L, Msl(L, s))
77Organization of Programming Languages-Cheng (Fall 2005)
Loop Meaning
The meaning of the loop is the value of theprogram variables after the statements in theloop have been executed the prescribednumber of times, assuming there have beenno errors
In essence, the loop has been converted fromiteration to recursion, where the recursivecontrol is mathematically defined by otherrecursive state mapping functions
Recursion, when compared to iteration, iseasier to describe with mathematical rigor
78Organization of Programming Languages-Cheng (Fall 2005)
Evaluation of DenotationalSemantics
Can be used to prove the correctness of programs Provides a rigorous way to think about programs Can be an aid to language design Has been used in compiler generation systems Because of its complexity, they are of little use to
language users
27
79Organization of Programming Languages-Cheng (Fall 2005)
Summary
BNF and context-free grammars are equivalentmeta-languages Well-suited for describing the syntax of
programming languages An attribute grammar is a descriptive formalism
that can describe both the syntax and thesemantics of a language
Three primary methods of semantics description Operational, axiomatic, denotational
Recommended