Implementation Syntax and Semantics Organization of Programming LanguagesCheng

Implementation, Syntax, and Semantics Organization of Programming Languages-Cheng (Fall 2005) 1

Implementation Methods u Compilation l Translate high-level program to machine code l Slow translation l Fast execution Source Program Input Compiler Target Program Organization of Programming Languages-Cheng (Fall 2005) Target Program Output 2

Compilation Process Organization of Programming Languages-Cheng (Fall 2005) Compiler 3

Implementation Methods u Pure interpretation l No translation l Slow execution l Becoming rare Source Program Interpreter Output Input Organization of Programming Languages-Cheng (Fall 2005) 4

Implementation Methods u Hybrid implementation systems l Small translation cost l Medium execution speed Source Program Intermediate Program Translator Virtual Machine Intermediate Program Output Input Organization of Programming Languages-Cheng (Fall 2005) 5

Hybrid Implementation System Organization of Programming Languages-Cheng (Fall 2005) Translator 6

Programming Environments u The collection of tools used in software development u UNIX l An older operating system and tool collection u Borland JBuilder l An integrated development environment for Java u Microsoft Visual Studio. NET l A large, complex visual environment l Used to program in C#, Visual BASIC. NET, Jscript, J#, or C++ Organization of Programming Languages-Cheng (Fall 2005) 7

Describing Syntax u Lexemes: u Tokens: lowest-level syntactic units categories of lexemes sum = x + 2 – 3 Lexemes: sum, =, x, +, 2, -, 3 Tokens: identifier, equal_sign, plus_op, integer_literal, minus_op Organization of Programming Languages-Cheng (Fall 2005) 8

Formal Method for Describing Syntax u Backus-Naur form (BNF) l Also equivalent to context-free grammars, developed by Noam Choamsky (a linguist) l BNF is a meta-language u l l 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 defined RHS: contains a mixture of tokens, lexemes, and references to other abstractions l l l Abstractions are called non-terminal symbols Lexemes and tokens are called terminal symbols Also contains a special non-terminal symbol called the start symbol Organization of Programming Languages-Cheng (Fall 2005) 9

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> Organization of Programming Languages-Cheng (Fall 2005) 10

Derivation u 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 = <var> - <var> end => begin A = B - C end Organization of Programming Languages-Cheng (Fall 2005) 11

BNF u Leftmost derivation: l the replaced non-terminal is always the leftmost non-terminal u Rightmost derivation l the replaced non-terminal is always the rightmost non-terminal u Sentential forms l Each string in the derivation, including <program> Organization of Programming Languages-Cheng (Fall 2005) 12

Derivation begin A = B + C; B = C end Rightmost: <program> (start symbol) => begin <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 Organization of Programming Languages-Cheng (Fall 2005) 13

Parse Tree u. A hierarchical structure that shows the derivation process Example: <assign> <id> = <expr> <id> A | B | C | D <expr> <id> + <expr> | <id> - <expr> | ( <expr> ) | <id> Organization of Programming Languages-Cheng (Fall 2005) 14

Parse Tree A = B * (A + C) <assign> Þ <id> = <expr> Þ A = <id> * <expr> Þ A = B * ( <expr> ) Þ A = B * ( <id> + <expr> ) Þ A = B * ( A + <id> ) ÞA=B*(A+C) Organization of Programming Languages-Cheng (Fall 2005) 15

Ambiguous Grammar u u u A grammar that generates a sentence for which there are two or more distinct parse trees is said to be ambiguous Example: <assign> <id> + <expr> <id> A | B | C | D <expr> + <expr> | <expr> * <expr> | ( <expr> ) | <id> Draw two different parse trees for A=B+C*A Organization of Programming Languages-Cheng (Fall 2005) 16

Ambiguous Grammar Organization of Programming Languages-Cheng (Fall 2005) 17

Ambiguous Grammar u Is the following grammar ambiguous? <if_stmt> if <logic_expr> then <stmt> | if <logic_expr> then <stmt> else <stmt> Organization of Programming Languages-Cheng (Fall 2005) 18

Operator Precedence A=B+C*A u How to force “*” to have higher precedence over “+”? u Answer: add more non-terminal symbols u Observe that higher precedent operator reside at “deeper” levels of the trees Organization of Programming Languages-Cheng (Fall 2005) 19

Operator Precedence A=B+C*A Before: After: <assign> <id> + <expr> <id> A | B | C | D <expr> + <expr> | <expr> * <expr> | ( <expr> ) | <id> <assign> <id> + <expr> <id> A | B | C | D <expr> + <term> | <term> * <factor> | <factor> ( <expr> ) | <id> Organization of Programming Languages-Cheng (Fall 2005) 20

Operator Precedence A=B+C*A Organization of Programming Languages-Cheng (Fall 2005) 21

Associativity of Operators A=B+C–D*F/G u Left-associative l Operators of the same precedence evaluated from left to right l C++/Java: +, -, *, /, % u Right-associative l Operators of the same precedence evaluated from right to left l C++/Java: unary -, unary +, ! (logical negation), ~ (bitwise complement) u How to enforce operator associativity using BNF? Organization of Programming Languages-Cheng (Fall 2005) 22

Associative of Operators <assign> <id> = <expr> <id> A | B | C | D <expr> + <term> | <term> * <factor> | <factor> ( <expr> ) | <id> Left-recursive rule Organization of Programming Languages-Cheng (Fall 2005) Left-associative 23

Associativity of Operators <assign> <id> = <factor> <exp> ^ <factor> | <exp> Right-recursive rule <exp> (<expr>) | <id> A | B | C | D Exercise: Draw the parse tree for A = B^C^D (use leftmost derivation) Organization of Programming Languages-Cheng (Fall 2005) 24

Extended BNF u BNF rules may grow unwieldy for complex languages u Extended BNF l Provide extensions to “abbreviate” the rules into much simpler forms l Does not enhance descriptive power of BNF l Increase readability and writability Organization of Programming Languages-Cheng (Fall 2005) 25

Extended BNF 1. Optional parts are placed in brackets ([ ]) <select_stmt> if ( <expr> ) <stmt> [ else <stmt> ] 2. Put alternative parts of RHSs in parentheses and separate them with vertical bars <term> (+ | -) const 3. Put repetitions (0 or more) in braces ({ }) <id_list> <id> { , <id> } Organization of Programming Languages-Cheng (Fall 2005) 26

Extended BNF (Example) BNF: <expr> + <term> | <expr> - <term> | <term> * <factor> | <term> / <factor> | <factor> <exp> ^ <factor> | <exp> ( <expr> ) | <id> EBNF: <expr> <term> {(+|-) <term>} <term> <factor>{(*|/)<factor>} <factor> <exp>{^ <exp>} <exp> ( <expr> ) | <id> Organization of Programming Languages-Cheng (Fall 2005) 27

Compilation Organization of Programming Languages-Cheng (Fall 2005) 28

Lexical Analyzer u u u A pattern matcher for character strings The “front-end” for the parser Identifies substrings of the source program that belong together => lexemes l Lexemes match a character pattern, which is associated with a lexical category called a token Example: sum = B – 5; Lexeme sum = B 5 ; Token ID (identifier) ASSIGN_OP ID SUBTRACT_OP INT_LIT (integer literal) SEMICOLON Organization of Programming Languages-Cheng (Fall 2005) 29

Lexical Analyzer u u Functions: 1. Extract lexemes from a given input string and produce the corresponding tokens, while skipping comments and blanks 2. Insert lexemes for user-defined names into symbol table, which is used by later phases of the compiler 3. Detect syntactic errors in tokens and report such errors to user How to build a lexical analyzer? l Create a state transition diagram first u u A state diagram is a directed graph Nodes are labeled with state names l u One of the nodes is designated as the start node Arcs are labeled with input characters that cause the transitions Organization of Programming Languages-Cheng (Fall 2005) 30

State Diagram (Example) Letter A | B | C |…| Z | a | b | … | z Digit 0 | 1 | 2 | … | 9 id Letter{(Letter|Digit)} int Digit{Digit} Organization of Programming Languages-Cheng (Fall 2005) main () { int sum = 0, B = 4; sum = B - 5; } 31

Lexical Analyzer u Need to distinguish reserved words from identifiers l e. g. , reserved words: main and int u identifiers: sum and B Use a table lookup to determine whether a possible identifier is in fact a reserved word To determine whether id is a reserved word Organization of Programming Languages-Cheng (Fall 2005) 32

Lexical Analyzer u Useful subprograms in the lexical analyzer: 1. lookup v 2. get. Char v 3. determines whether the string in lexeme is a reserved word (returns a code) reads the next character of input string, puts it in a global variable called next. Char, determines its character class (letter, digit, etc. ) and puts the class in char. Class add. Char v Appends next. Char to the current lexeme Organization of Programming Languages-Cheng (Fall 2005) 33

Lexical Analyzer int lex() { switch (char. Class) { case LETTER: add. Char(); get. Char(); while (char. Class == LETTER || char. Class == DIGIT) { add. Char(); get. Char(); } return lookup(lexeme); break; case DIGIT: add. Char(); get. Char(); while (char. Class == DIGIT) { add. Char(); get. Char(); } return INT_LIT; break; } /* End of switch */ } /* End of function lex */ Organization of Programming Languages-Cheng (Fall 2005) 34

Parsers (Syntax Analyzers) u Goals of a parser: l Find all syntax errors l Produce parse trees for input program u Two categories of parsers: l Top down u produces the parse tree, beginning at the root u Uses leftmost derivation l Bottom up u produces the parse tree, beginning at the leaves u Uses the reverse of a rightmost derivation Organization of Programming Languages-Cheng (Fall 2005) 35

Recursive Descent Parser u. A top-down parser implementation u Consists of a collection of subprograms l A recursive descent parser has a subprogram for each non-terminal symbol u If there are multiple RHS for a given nonterminal, l parser must make a decision which RHS to apply first l A x… | y…. | z…. | … l The correct RHS is chosen on the basis of the next token of input (the lookahead) Organization of Programming Languages-Cheng (Fall 2005) 36

Recursive Descent Parser void expr() { term(); <expr> <term> {(+|-) <term>} while ( next. Token ==PLUS_CODE || <term> <factor> {(*|/) <factor>} next. Token == MINUS_CODE <factor> id | ( <expr> ) ) { lex(); term(); } } 1. lex() is the lexical analyzer function. It gets the next lexeme and puts its token code in the global variable next. Token 2. All subprograms are written with the convention that each one leaves the next token of input in next. Token 3. Parser uses leftmost derivation Organization of Programming Languages-Cheng (Fall 2005) 37

Recursive Descent Parser void factor() { /* Determine which RHS */ if (next. Token == ID_CODE) <expr> <term> {(+|-) <term>} lex(); <term> <factor> {(*|/) <factor>} else if (next. Token == <factor> id | ( <expr> ) LEFT_PAREN_CODE) { lex(); expr(); if (next. Token == RIGHT_PAREN_CODE) lex(); else error(); } else error(); /* Neither RHS matches */ } Organization of Programming Languages-Cheng (Fall 2005) 38

Recursive Descent Parser u Problem with left recursion l A A + B (direct left recursion) l A B c D (indirect left recursion) B Ab l A grammar can be modified to remove left recursion u Inability to determine the correct RHS on the basis of one token of lookahead l Example: A a. C | Bd B ac C c Organization of Programming Languages-Cheng (Fall 2005) 39

LR Parsing u LR Parsers are almost always table-driven l Uses a big loop to repeatedly inspect 2 -dimen table to find out what action to take l Table is indexed by current input token and current state l Stack contains record of what has been seen SO FAR (not what is expected/predicted to see in future) u PDA: Push down automata: l State diagram looks just like a DFA state diagram l Arcs labeled with <input symbol, top-of-stack symbol> Organization of Programming Languages-Cheng (Fall 2005) 40

PDAs u LR PDA: is a recognizer l Builds a parse tree bottom up l States keep track of which productions we “might” be in the middle of. Organization of Programming Languages-Cheng (Fall 2005) 41

Example 1. <pgm> -> <stmt list> $$ <stmt list> -> <stmt list> <stmt> | <stmt> -> id : = <expr> | read id | write <expr> -> <term> | <expr> <add op> <term> -> <factor> | <term> <mult op> <factor> -> ( <expr> ) | id | literal <add op> -> + | <mult op> -> * | / 2. 3. 4. 5. read A read B sum : = A + B write sum / 2 See handout for trace of parsing. Organization of Programming Languages-Cheng (Fall 2005) 42

STOP Organization of Programming Languages-Cheng (Fall 2005) 43

Static Semantics u u BNF cannot describe all of the syntax of PLs Examples: l All variables must be declared before they are referenced l The end of an ADA subprogram is followed by a name, that name must match the name of the subprogram Procedure Proc_example (P: in Object) is begin …. end Proc_example u u Static semantics l Rules that further constrain syntactically correct programs l In most cases, related to the type constraints of a language l Static semantics are verified before program execution (unlike dynamic semantics, which describes the effect of executing the program) BNF cannot describe static semantics Organization of Programming Languages-Cheng (Fall 2005) 44

Attribute Grammars (Knuth, 1968) u A BNF grammar with the following additions: 1. For each symbol x there is a set of attribute values, A(x) u u u 2. Each grammar rule has a set of functions that define certain attributes of the nonterminals in the rule u 3. 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 Rule: X 0 X 1 … Xj … Xn S(X 0) = f (A(X 1), …, A(Xn)) I(Xj) = f (A(X 0), …, A(Xj-1)) A (possibly empty) set of predicate functions to check whether static semantics are violated u of. Example: ? 2005) Organization Programming S(X Languages-Cheng j ) = I (Xj ) (Fall 45

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 Organization of Programming Languages-Cheng (Fall 2005) 46

Attribute Grammars (Example) u Expressions of the form <var> + <var> l var's can be either int_type or real_type l If both var’s are int, result of expr is int l If at least one of the var’s is real, result of expr is real u BNF <assign> <var> = <expr> <var> + <var> | <var> A | B | C u (Rule 1) (Rule 3) (Rule 4) (Rule 2) Attributes for non-terminal symbols <var> and <expr> l actual_type - synthesized attribute for <var> and <expr> l expected_type - inherited attribute for <expr> Organization of Programming Languages-Cheng (Fall 2005) 47

Attribute Grammars (Example) 1. 2. 3. 4. 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 int else real end if Predicate: <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 | C Semantic rule: <var>. actual_type lookup(<var>. string) Note: Lookup function looks up a given variable name in the symbol table and returns the variable’s type Organization of Programming Languages-Cheng (Fall 2005) 48

Parse Trees for Attribute Grammars A=A+B <assign> <expr> <var> A var[2] = A var[3] + B How 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. Organization of Programming Languages-Cheng (Fall 2005) 49

Parse Trees for Attribute Grammars A=A+B 1. 2. 3. 4. <assign> <var> = <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 real end 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) 1. <var>. actual_type lookup(A) (Rule 4) 2. <expr>. expected_type <var>. actual_type (Rule 1) 3. <var>[2]. actual_type lookup(A) (Rule 4) <var>[3]. actual_type lookup(B) (Rule 4) 4. <expr>. actual_type either int or real (Rule 2) 5. <expr>. expected_type = <expr>. actual_type is either TRUE or FALSE (Rule 2) Organization of Programming Languages-Cheng (Fall 2005) 50

Parse Trees for Attribute Grammars Predicate test 5 2 4 1 3 Organization of Programming Languages-Cheng (Fall 2005) 4 3 51

Attribute Grammar Implementation u Determining attribute evaluation order is a complex problem, requiring the construction of a dependency graph to show all attribute dependencies u Difficulties in implementation l The large number of attributes and semantic rules required make such grammars difficult to write and read l Attribute values for large parse trees are costly to evaluate u Less formal attribute grammars are used by compiler writers to check static semantic rules Organization of Programming Languages-Cheng (Fall 2005) 52

Describing (Dynamic) Semantics <for_stmt> for (<expr 1>; <expr 2>; <expr 3>) <assign_stmt> <var> = <expr>; What is the meaning of each statement? l dynamic semantics How do we formally describe the dynamic semantics? Organization of Programming Languages-Cheng (Fall 2005) 53

Describing (Dynamic) Semantics u There is no single widely acceptable notation or formalism for describing dynamic semantics u Three formal methods: Operational Semantics Axiomatic Semantics Denotational Semantics 1. 2. 3. Organization of Programming Languages-Cheng (Fall 2005) 54

Operational Semantics u Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The change in the state of the machine (memory, registers, etc. ) defines the meaning of the statement. Execute Statement Initial State: Final State: (i 1, v 1), (i 2, v 2), … (i 1, v 1’), (i 2, v 2’), … Organization of Programming Languages-Cheng (Fall 2005) 55

Operational Semantics u To use operational semantics for a high-level language, a virtual machine in needed. l A hardware pure interpreter would be too expensive l A software pure interpreter also has problems: 1. The detailed characteristics of the particular computer would make actions difficult to understand 2. Such a semantic definition would be machine dependent. Organization of Programming Languages-Cheng (Fall 2005) 56

Operational Semantics Approach: use a complete computer simulation 1. Build a translator (translates source code to the machine code of an idealized computer) 2. Build a simulator for the idealized computer u Example: C Statement: Operational Semantics: u for (expr 1; expr 2; expr 3) { … } expr 1; loop: if expr 2 = 0 goto out … expr 3; goto loop out: … Organization of Programming Languages-Cheng (Fall 2005) 57

Operational Semantics u Valid statements for the idealized computer: iden = var iden = iden + 1 iden = iden – 1 goto label if var relop var goto label u Evaluation of Operational Semantics: l Good if used informally (language manuals, etc. ) l Extremely complex if used formally (e. g. , VDL) Organization of Programming Languages-Cheng (Fall 2005) 58

Axiomatic Semantics u Based on formal logic (first order predicate calculus) u Approach: l Each statement is preceded and followed by a logical expression that specifies constraints on program variables u l The logical expressions are called predicates or assertions Define axioms or inference rules for each statement type in the language u to allow transformations of expressions to other expressions Organization of Programming Languages-Cheng (Fall 2005) 59

Axiomatic Semantics {P} A = B + 1 {Q} where P: precondition Q: postcondition u u Precondition: an assertion before a statement that states the relationships and constraints among variables that are true 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} l Postcondition: A > 1 l One possible precondition: {B > 10} l Weakest precondition: {B > 0} Organization of Programming Languages-Cheng (Fall 2005) 60

Axiomatic Semantics u u Program proof process: l The postcondition for the whole program is the desired results. l Work back through the program to the first statement. l 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 u u u (P is computed with all instances of x replaced by E) Example: a = b / 2 – 1 {a < 10} Weakest precondition: b/2 – 1 < 10 Axiomatic Semantics for assignment: {Qx E } x = E {Q} Organization of Programming Languages-Cheng (Fall 2005) => b < 22 61

Axiomatic Semantics u Inference rule for Sequences: {P 1} S 1 {P 2}, {P 2} S 2 {P 3} {P 1} S 1; S 2 {P 3} u Example: Y = 3 * X + 1; X = Y + 3; {X < 10} l Precondition for second statement: {Y < 7} l Precondition for first statement: {X < 2} Y = 3 * X + 1; X = Y + 3; {X < 10} Organization of Programming Languages-Cheng (Fall 2005) 62

Denotational Semantics u Based on recursive function theory u The meaning of language constructs are defined by the values of the program's variables u The process of building a denotational specification for a language: 1. Define a mathematical object for each language entity 2. Define a function that maps instances of the language entities onto instances of the corresponding mathematical objects Organization of Programming Languages-Cheng (Fall 2005) 63

Denotational Semantics u Decimal Numbers l The following denotational semantics description maps decimal numbers as strings of symbols into numeric values l 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) l Denotational Semantics: Mdec('0') = 0, Mdec ('1') = 1, …, Mdec ('9') = 9 Mdec (<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 nonnegative decimal integer values Organization of Programming Languages-Cheng (Fall 2005) 64