Lecture 3 Concepts of Programming Languages Arne Kutzner Hanyang University / Seoul Korea

Concepts of Programming LanguagesL2.2 Topics Formal Methods of Describing Syntax / BNF and Context free grammars Attribute Grammars Describing the Meanings of Programs / Semantics

Concepts of Programming LanguagesL2.3 Introduction Syntax: form and structure of the program code Semantics: meaning of the program code (meaning of expressions, statements, control structures, …) Syntax and semantics provide a language’s definition – Users of a language definition Implementers Programmers (the users of the language)

Concepts of Programming LanguagesL2.4 General Problem of Describing Syntax: Terminology A sentence is a string of characters over some alphabet A language is a set of sentences A lexeme is the lowest level syntactic unit of a language (e.g., *, sum, begin ) A token is a category of lexemes (e.g., identifier)

Concepts of Programming LanguagesL2.5 Formal Definition of Languages Generators (Grammars) –A device that generates sentences of a language –One can determine if the syntax of a particular sentence is syntactically correct by comparing it to the structure of the generator Recognizers (Parser) –A recognition device reads input strings over the alphabet of the language and decides whether the input strings belong to the language –Example: syntax analysis part of a compiler We will first look into the world of generators and later we will study the recognizer

Concepts of Programming LanguagesL2.6 BNF / Context-Free Grammars Context-Free Grammars (CFG) –Developed by Noam Chomsky in the mid-1950s –Language generators, meant to describe the syntax of natural languages –Define a class of languages called context-free languages Backus-Naur Form (1959) –Invented by John Backus to describe Algol 58 BNF and context-free grammars represent equal concepts

Concepts of Programming LanguagesL2.7 BNF (CFG) Fundamentals In BNF, abstractions are used to represent classes of syntactic structures--they act like syntactic variables (also called nonterminal symbols, or just nonterminals) Terminals are lexemes or tokens A rule has a left-hand side (LHS), which is a nonterminal, and a right- hand side (RHS), which is a string of terminals and/or nonterminals

Concepts of Programming LanguagesL2.8 BNF / GCF grammar Rules An abstraction (or nonterminal symbol) can have more than one RHS  | begin end

Concepts of Programming LanguagesL2.9 BNF (CFG) Fundamentals Nonterminals are often enclosed in angle brackets –Examples of BNF rules: → identifier | identifier, → if then Grammar: a finite non-empty set of rules A start symbol is a special element of the nonterminals of a grammar

Concepts of Programming LanguagesL2.10 CFG - Formal Definition A context-free grammar G is defined by the 4-tuple G = (V, Σ, R, S) where 1.V is a finite set; each element v in V is called a non- terminal character or a variable. Each variable represents a different type of phrase or clause in the sentence. 2.Σ is a finite set of terminals, disjoint from V, which make up the actual content of the sentence. The set of terminals is the alphabet of the language defined by the grammar G. 3.R is a finite relation from V to (V + Σ)*, where the asterisk represents the Kleene star operation. The members of R, are called the (rewrite) rules or productions of the grammar. (also commonly symbolized by a P) 4.S is the start variable (or start symbol), used to represent the whole sentence (or program). It must be an element of V.

Concepts of Programming LanguagesL2.11 Example: Describing Lists Syntactic lists are described using recursion  ident | ident ','

Concepts of Programming LanguagesL2.12 Derivation A derivation is a repeated application of rules, starting with the start symbol and ending with a sentence (all terminal symbols)

Concepts of Programming LanguagesL2.13 An Example Grammar   | ';'  '='  'a' | 'b' | 'c' | 'd'  '+' | '-'  | 'const'

Concepts of Programming LanguagesL2.14 An Example Derivation => => => = => a = => a = + => a = b + => a = b + const

Concepts of Programming LanguagesL2.15 Derivations – Some Notions Every string of symbols in a derivation is a sentential form A sentence is a sentential form that has only terminal symbols A leftmost derivation is one in which the leftmost nonterminal in each sentential form is the one that is expanded. Accordingly a rightmost derivation for the rightmost nonterminal. –A derivation may be neither leftmost nor rightmost

Concepts of Programming LanguagesL2.16 Parse Tree A parse tree represents a hierarchical representation of a derivation by means of a tree. Example: const a = b +

Concepts of Programming LanguagesL2.17 Ambiguity in Grammars A grammar is ambiguous if and only if it generates a sentential form (the language generated by the grammar comprises at least one word) that has two or more distinct parse trees

Concepts of Programming LanguagesL2.18 Example for Ambiguous Grammar  | const  / | - const -/ const -/ word: const – const / const

Concepts of Programming LanguagesL2.19 Unambiguous Grammar Grammar on the slide before in unambiguous form: –We get some form of operator precedence  - |  / const | const const / -

Concepts of Programming LanguagesL2.20 Associativity of Operators Operator associativity can also be indicated by a grammar. Example: -> + | const (ambiguous) -> + const | const (unambiguous) const + +

Concepts of Programming LanguagesL2.21 The empty word ε Grammars can comprise rules of the form:  ε ε is the empty word; the above rule indicates that the non-terminal can be deleted without any replacement We will use the empty world later in the context of parsers.

Concepts of Programming LanguagesL2.22 Extended BNF Optional parts are placed in brackets [ ] -> ident [( )] Alternative parts of RHSs are placed inside parentheses and separated via vertical bars -> (+|-) const Repetitions (0 or more) are placed inside braces { } -> letter {letter|digit}

Concepts of Programming LanguagesL2.23 BNF and EBNF - Examples BNF  + | - |  * | / | EBNF  {(+ | -) }  {(* | /) }

Concepts of Programming LanguagesL2.24 Variations in EBNF Use of a colon instead of -> Use of opt for optional parts Use of oneof for choices

Concepts of Programming LanguagesL2.25 Static Semantics Nothing to do with meaning Context-free grammars (CFGs) cannot describe all of the syntax of programming languages Categories of constructs that are “trouble- maker”: –Still Context-free, but cumbersome (e.g., types of operands in expressions) –Non-context-free (e.g., variables must be declared before they are used)

Concepts of Programming LanguagesL2.26 Attribute Grammars Attribute grammars (AGs) have additions to CFGs to carry some semantic info on parse tree nodes Primary value of AGs: –Static semantics specification for static semantics checks

Concepts of Programming LanguagesL2.27 Attribute Grammars : Definition Def: An attribute grammar is a context-free grammar with the following additions: –For each grammar symbol x there is a set A(x) of attribute values –Each rule has a set of functions that define certain attributes of the nonterminals in the rule –Each rule has a (possibly empty) set of predicates to check for attribute consistency

Concepts of Programming LanguagesL2.28 Attribute Grammars: Definition Let X 0  X 1... X n be a rule Functions of the form S(X 0 ) = f(A(X 1 ),..., A(X n )) define synthesized attributes Functions of the form I(X j ) = f(A(X 0 ),..., A(X n )), for 1 <= j <= n, define inherited attributes Initially, there are intrinsic attributes on the leaves

Concepts of Programming LanguagesL2.29 Attribute Grammars: An Example Syntax -> = -> + | -> id Attributes –actual_type : synthesized with the non- terminals and –expected_type : inherited with the non- terminal

Concepts of Programming LanguagesL2.30 Attribute Grammar (Example) Syntax rule:  = Semantic rules:.expected_type .actual_type Syntax rule:  id Semantic rule:.actual_type  lookup (id.type) Syntax rule:  Semantic rules:.actual_type .actual_type Predicate:.expected_type ==.actual_type Syntax rule:  [1] + [2] Semantic rules:.actual_type  [1].actual_type Predicate: [1].actual_type == [2].actual_type.expected_type ==.actual_type

Concepts of Programming LanguagesL2.31 Attribute Grammars (continued) How are attribute values computed? –If all attributes were synthesized, the tree could be decorated in bottom-up order. –If all attributes were inherited, the tree could be decorated in top-down order. –In many cases, both kinds of attributes are used, and it is some combination of top- down and bottom-up that must be used.

Concepts of Programming LanguagesL2.32 Semantics There is no single generally, widely accepted notation or formalism for describing program semantics We have several general approaches: –Operational Semantics (Behavior oriented) –Axiomatic Semantics (Formal Logic, Predicate calculus oriented) –Denotational Semantics (Domain oriented)

Concepts of Programming LanguagesL2.33 Operational Semantics Approach 1: Describe the meaning of the language constructs by using clean and unambiguous natural language in mix with formal elements Example: Current ISO C++ standard (ISO/IEC 14882:2012(E) )

Concepts of Programming LanguagesL2.34 Operational Semantics (continued) Approach 2: Use some form of formal method/machinery as description tool. Examples: –Vienna Definition Language (VDL) –Formal (state) machine approach. You get the meaning of some code by executing it on a formal machine May require a translation scheme for getting formal machine code out of language code. –Use a mathematical formal system like a calculus as replacement for the formal machine in the above approach

Concepts of Programming LanguagesL2.35 Operational Semantics (continued) Uses of operational semantics: –Language definition itself for compiler constructors as well as language users. –Proofing the correctness of automatic program transformations/optimizations. Later we will meet some form of operational semantics...

Concepts of Programming LanguagesL2.36 Axiomatic Semantics Based on formal logic (predicate calculus) Original purpose: Formal program verification Axioms or inference rules are defined for each statement type in the language (to allow transformations of logic expressions into more formal logic expressions) The logic expressions are called assertions

Concepts of Programming LanguagesL2.37 Logic Implications P implies Q (symbolized as P ⇒ Q) Meaning: –If condition P is true, then condition Q must be true –If condition P is false, the implication is true independent of the value of Q As logic table: PQ P ⇒ Q TTT TFF FTT FFT

Concepts of Programming LanguagesL2.38 Logic Implications Example: b>10 ⇒ b>5 Proof: (Range check for b) b in [11..infinite] b>10 is true and b>5 is true b in [6..10] b>10 is false and b>5 is true b in [-infinite..5] b>10 is false and b>5 is false Intuition: With respect to the range of all integers b>10 is “more often false”, then b>5. So the condition b>10 it is less general and more restrictive; We say it is a stronger condition.

Concepts of Programming LanguagesL2.39 Logic Implications Weaker versus stronger conditions: P ⇒ Q stronger conditionweaker condition P is a stronger condition then Q and Q is a weaker condition then P

Concepts of Programming LanguagesL2.40 Axiomatic Semantics Form {P} statement {Q} PreconditionPostcondition Preconditions and postconditions are called assertions and will be evaluated to either true or false The pair of a prepcondition and postcondition is called a specification. A statement is correct with respect to its specification, if pre-condition and post-condition become true

Concepts of Programming LanguagesL2.41 Axiomatic Semantics Form An example –a = b + 1 {a > 1} –One possible precondition: {b > 10} –Weakest precondition: {b > 0} A weakest precondition is the least restrictive precondition that will guarantee the postcondition

Concepts of Programming LanguagesL2.42 Inference rules H 1, H 2,..., H n H This notation can be interpreted as: If H 1, H 2,..., H n have all been verified, we may conclude that H is valid.

Concepts of Programming LanguagesL2.43 Rule of consequence Meaning: We can strengthen the precondition and we can weaken the postcondition in order to get a fresh “valid” specification Example: a = b / 2 - 1,b>30 ⇒ b>22, a>10 ⇒ a>5 {b > 22} a = b / {a > 5} {b > 30} {a > 10}

Concepts of Programming LanguagesL2.44 Axiomatic Semantics: Axioms An axiom for assignment statements (x = E): {Q x->E } x = E {Q} Delivers the weakest precondition for Q a = b / {a > 10} b / 2 – 1 > 10 => b > 22 {b > 22} QE x

Concepts of Programming LanguagesL2.45 Sequences {P1} S1 {Q}, {Q} S2 {P2} {P1} S1; S2 {P2} y = 3 * x + 1; x = y + 3; {x < 10} y + 3 y < 7 {y < 7} 3 * x + 1 x < 2 {x < 2}

Concepts of Programming LanguagesL2.46 Selection Statements {B and P} S1 {Q}, {(not B) and P} S2 {Q} {P} if B then S1 else S2 {Q} if x > 0 then a = y - 1 else a = y + 1 {y > 1} a = y – 1 {a > 0} {y > -1} a = y + 1 {a > 0} {y > 1} {a > 0} and x > 0 and not (x > 0) apply the rule of consequence

Concepts of Programming LanguagesL2.47 Axiomatic Semantics: while Inference rule for logical pretest loops where I is the loop invariant (the inductive hypothesis) Axiomatic description for while loops: {P} while B do S end {Q}

Concepts of Programming LanguagesL2.48 Loop Invariant Requirements The loop invariant must satisfy the following requirements in order to be useful: 1.P => I (precondition implies invariant) 2.{I and B} S {I} (axiomatic semantics during loop iteration / the condition B is true) 3.{I and (not B)} => Q (invariant at termination implies postcondition) 4.loop terminates

Concepts of Programming LanguagesL2.49 Finding a loop invariant … Example: while y != x do y = y + 1 end {y = x} One possible technique: unroll the loop.. Zero iterations: {y = x} One iteration: {y = x - 1} y = y + 1 {y = x} Two iterations: {y = x – 2} y = y + 1 {y = x - 1} Three iterations: {y = x – 3} y = y + 1 {y = x - 2} y <= x assumed loop invariant …

Concepts of Programming LanguagesL2.50 Check whether the loop invariant is a (weakest) precondition We select P as {y <= x} and I as {y <= x} : 1.P = I directly implies P=>I 2.{I and B} S {I} We have: {y <= x and y != x} y = y + 1 {y <= x} Verification: We get {y + 1 <= x}, which is equivalent to {y < x}, equivalent to {y <= x and y != x} 3.{I and (not B)} => Q We have: {(y {y = x} this is trivially true … 4.Loop terminates obviously So, the loop invariant can be used as precondition. Further it represents a weakest precondition

Concepts of Programming LanguagesL2.51 Loop invariant as weakest precondition Unrolling and using the invariant as precondition may not deliver a weakest precondition Example: while s > 1 do s = s / 2 end {s = 1} As loop invariant we get by unrolling: {s is a nonnegative power of 2} However, a much broader correct precondition is {s > 1}

Concepts of Programming LanguagesL2.52 Evaluation of Axiomatic Semantics Developing axioms or inference rules for all of the statements in a language is difficult It is a good tool for correctness proofs, and an excellent framework for reasoning about programs, but it is not as useful for language users and compiler writers Its usefulness in describing the meaning of a programming language is limited for language users or compiler writers

Concepts of Programming LanguagesL2.53 Denotational Semantics Based on recursive function theory The most abstract semantics description method Originally developed by Scott and Strachey (1970)

Concepts of Programming LanguagesL2.54 Denotational Semantics Characteristics of denotational semantics: –Defined on the foundation of a mathematical structure call (scott-)domain, –Domain elements represent program outcomes as single mathematical objects –Maps sentences of the language to domain elements –Difficult point: Non-termination. A domain comprises an entity ┴ (pronounced bot or bottom) that represents all non-terminating sentences (programs) The problem, whether an arbitrary program terminates or not is not decidable 

Concepts of Programming LanguagesL2.55 Example Semantics Operational semantics with denotational elements for a small language with: –Numbers, –Assignments, –Boolean evaluation, –while construct

Concepts of Programming LanguagesL2.56 Central Idea: Program State The state of a program is the values of all its current variables s = {,, …, } Let VARMAP be a function that, when given a variable name and a state, returns the current value of the variable VARMAP(i j, s) = v j

Concepts of Programming LanguagesL2.57 Decimal Numbers  '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' | ('0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9') M dec ('0') = 0, M dec ('1') = 1, …, M dec ('9') = 9 M dec ( '0') = 10 * M dec ( ) M dec ( '1’) = 10 * M dec ( ) + 1 … M dec ( '9') = 10 * M dec ( ) + 9 ‘ Syntax v Semantic interpreattion

Concepts of Programming LanguagesL2.58 Expressions Map expressions onto Z  {error} We assume expressions are decimal numbers, variables, or binary expressions having one arithmetic operator and two operands, each of which can be an expression

Concepts of Programming LanguagesL2.59 Expressions M e (, s)  = case of => M dec (, s) => if VARMAP(, s) == undef then error else VARMAP(, s) => if (M e (., s) == undef OR M e (., s) = undef) then error else if (. == ' + ' then M e (., s) + M e (., s) else M e (., s) * M e (., s)...

Concepts of Programming LanguagesL2.60 Assignment Statements Maps state sets to state sets M a (x := E, s)  = if M e (E, s) == error then error else s’ = {,,..., }, where for j = 1, 2,..., n, if i j == x then v j ’ = M e (E, s) else v j ’ = VARMAP(i j, s)

Concepts of Programming LanguagesL2.61 Logical Pretest Loops Maps state sets to state sets M l (while B do L, s)  = if M b (B, s) == undef then error else if M b (B, s) == false then s else if M sl (L, s) == error then error else M l (while B do L, M sl (L, s)) Recursive unfolding of the iteration

Concepts of Programming LanguagesL2.62 Loop Meaning The meaning of the loop is the value of the program variables after the statements in the loop have been executed the prescribed number of times, assuming there have been no errors –In the case of non-termination of the loop the example semantics will never deliver any value.  In essence, the loop has been converted from iteration to recursion, where the recursive control is mathematically defined by other recursive state mapping functions