Presentation is loading. Please wait.

Presentation is loading. Please wait.

Dec 16. 2003Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI.

Similar presentations


Presentation on theme: "Dec 16. 2003Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI."— Presentation transcript:

1 Dec 16. 2003Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI

2 Dec 16. 2003Formal Semantics2 Contents Leif’s three parts of the course: Functional programming Logical programming Similar ways of thinking, but different from the imperative way Formal semantics

3 Dec 16. 2003Formal Semantics3 Formal Semantics? You have seen informal semantics (meaning) earlier in the course Most languages don’t have a complete formal specification Why defining a formal specification? –Possibility to make proofs of programs –The compiler may be validated –Easier to build a compiler! No agreed standard to describe semantics

4 Dec 16. 2003Formal Semantics4 Principal methods Operational semantics –Define the language by describing its actions as operations of a machine –The machine has to be precisely defined Denotational semantics –Uses mathematical functions on programs –Programs are translated into functions –Standard mathematical theory of functions is used Axiomatic semantics –Uses mathematical logic –Pre and post conditions –Aimed specifically at correctness proofs

5 Dec 16. 2003Formal Semantics5 Principal methods, cont. The three methods are based on BNF-rules (Backus-Naur Form) Syntax described in BNF – semantics is the rest, i.e. –Static types (could be syntax) –Semantic rules Important properties for the semantics: –Completeness: all correct programs will get semantics –Consistence: one program -> one unique description –Independence: should be minimal

6 Dec 16. 2003Formal Semantics6 A small example language expr  expr + term | expr - term | term term  term * factor | factor factor  ( expr ) | number number  number digit | digit digit  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Example: 4 * (50 - 3)

7 Dec 16. 2003Formal Semantics7 Expand the example Let’s add variables, statements, and assignments: factor  ( expr ) | number | identifier program  stmtList stmtList  stmt ; stmtList | stmt stmt  identifier := expr identifier  identifier letter | letter letter  a | b | c | … | z

8 Dec 16. 2003Formal Semantics8 Example of a program a := 2 + 3 ; b := a * 4 ; a := b - 5 ; Will result in: b=20 and a=15 {b=20, a=15} represents the semantics of this program –A function from the set of identifiers to integers –We will call this function an environment Env (I) = 15 if I = a 20 if I = b undef otherwise

9 Dec 16. 2003Formal Semantics9 Operations on environments Env : Identifier  Integer  {undef} Lookup: Env (I) Adding: Env & {I = n} The empty environment: Env 0 (I) = undef for all I More complex environments include pointers, aliases, scope information

10 Dec 16. 2003Formal Semantics10 Expand a little bit more Let’s add if and while statements: stmt  assignStmt | ifStmt | whileStmt assignStmt  identitfier := expr ifStmt  if expr then stmtList else stmtList fi whileStmt  while expr do stmtList od Expressions are True if the value > 0

11 Dec 16. 2003Formal Semantics11 An example n := 0 - 5 ; if n then i := n else i := 0 - n fi ; f := 1 ; while i do f := f * i ; i := i - 1 od The semantics is {n=5, i=0, f=120}

12 Dec 16. 2003Formal Semantics12 An abstract syntax A simplified version of the syntax Useful, since the parsing already done The program is correct To make it more compact we use: P: ProgramL: Statement list S: StatementE: Expression N: NumberD: Digit I: IdentifierA: Letter

13 Dec 16. 2003Formal Semantics13 The abstract syntax P  L L  L 1 ; L 2 | S S  I := E | if E then L 1 else L 2 fi | while E do L od E  E 1 + E 2 | E 1 - E 2 | E 1 * E 2 | ( E 1 ) | N N  N 1 D | D D  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 I  I 1 A | A A  a | b | c | … | z

14 Dec 16. 2003Formal Semantics14 Abstract syntax, cont. Semantic rules are defined for each right- hand side in terms of the semantics for their parts Note that the indexes on the letters are important Important to distinguish between + and the ordinary + A rule will tell us to replace + by + later

15 Dec 16. 2003Formal Semantics15 Operational semantics Describes how a program is to be executed on a known machine If the machine is a computer, the operational semantics is a translator (compiler) from the language to machine code for the computer Fortran and C has been defined this way The machine could also be an abstract machine, simple enough to be understood and simulated by hand

16 Dec 16. 2003Formal Semantics16 A reduction machine Our example language may be translated to semantic values using reduction rules: ( 3 + 4 ) * 5  (add the numbers) (7) * 5  (drop parentheses) 7 * 5  (multiply the numbers) 35 The rules are similar to logical inference rules

17 Dec 16. 2003Formal Semantics17 Logical inference rules The rules are written in the form: – premise conclusion For example:a + b = c b + a = c a  b, b  c a  c

18 Dec 16. 2003Formal Semantics18 Logical inference rules, cont. If we don’t have a premise, the rule is called an axiom: a + 0 = a Often written as: a + 0 = a

19 Dec 16. 2003Formal Semantics19 Reduction rules: arithmetics We have the following abstract semantics: E  E 1 + E 2 | E 1 - E 2 | E 1 * E 2 | ( E 1 ) | N N  N 1 D | D D  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 E: Expression, N: Number, D: Digit This may look complicated but we have to give the semantics somewhere

20 Dec 16. 2003Formal Semantics20 Reduction rules, cont. First all the digits (axioms) 0  0, 1  1, …, 9  9(rule 1) Numbers (rule 2): V0  10*V, V1  10*V+1,…, V9  10*V+9 And the operations (rule 3-6): V 1 + V 2  V 1 + V 2 V 1 - V 2  V 1 - V 2 V 1 * V 2  V 1 * V 2 ( V )  V

21 Dec 16. 2003Formal Semantics21 Reduction rules, expressions Expressions may be reduced in steps if they contain of two expression with an operator between (rule 7-9) E  E 1 E + E 2  E 1 + E 2 E  E 1 E - E 2  E 1 - E 2 E  E 1 E * E 2  E 1 * E 2

22 Dec 16. 2003Formal Semantics22 Reduction rules, cont. If the left side of an operator has evaluated to a value, then evaluate the right side (rule 10-12): E  E 1 V + E  V + E 1 E  E 1 V - E  V - E 1 E  E 1 V * E  V * E 1

23 Dec 16. 2003Formal Semantics23 Reduction rules, cont. Reduce the expression inside parentheses: (rule 13) Transitivity – expressions may be evaluated in steps (rule 14) E  E 1 ( E )  ( E 1 ) E  E 1, E 1  E 2 E  E 2

24 Dec 16. 2003Formal Semantics24 Example of a reduction We start with the expression: 2 * (3 + 4) – 5  (rule 1, 7) 2 * (3 + 4) – 5  (rule 1, 10) 2 * (3 + 4) – 5  (rule 3) 2 * (7) – 5  (rule 1, 12) 2 * 7 – 5  (rule 5) 14 – 5  (rule 11, 1) 14 – 5  (rule 4) 9

25 Dec 16. 2003Formal Semantics25 Adding environments Recall the rest of the abstract syntax: P  L L  L 1 ; L 2 | S S  I := E | if E then L 1 else L 2 fi | while E do L od E  E 1 + E 2 | E 1 - E 2 | E 1 * E 2 | ( E 1 ) | N P: ProgramL: Statement list S: StatementE: Expression We have to add an environment: Env : Identifier  Integer  {undef} It has to be updated in the reduction rules

26 Dec 16. 2003Formal Semantics26 Environments, cont. indicates that E evaluates in the environment Env Most rules do not change Env: If Env changes, we have a side effect 

27 Dec 16. 2003Formal Semantics27 Environments, cont. If I has the value V (rule 15): A rule for assignment (rule 16):  Expressions in assignments (rule 17): Env (I) = V 

28 Dec 16. 2003Formal Semantics28 Environments, cont. A statement sequence (rule 18): A program needs an empty environment (rule 19): L  

29 Dec 16. 2003Formal Semantics29 A small example The program: a := 2 + 3 ; b := a * 4 ; a := b - 5 ; Rule 19 gives: a := 2 + 3 ; b := a * 4 ; a := b - 5 ; 

30 Dec 16. 2003Formal Semantics30 Example, cont. Rules 3 gives:   And rule 16, 17:   {a=5} Rule 18: 

31 Dec 16. 2003Formal Semantics31 Example, cont. Rule 15, 9, 5, 16, 17:   <| {a=5, b=20} Rule 18:  And then:  {a=5, b=20} & {a=15} = {a=15, b=20}

32 Dec 16. 2003Formal Semantics32 if and while statements Recall the abstract syntax: S  I := E | if E then L 1 else L 2 fi | while E do L od I: IdentifierL: Statement list S: StatementE: Expression We need three rules for the if statement:

33 Dec 16. 2003Formal Semantics33 The if statement  V > 0  V ≤ 0 

34 Dec 16. 2003Formal Semantics34 The while statement , V ≤ 0  Env , V > 0  Note that the second rule is recursive!

35 Dec 16. 2003Formal Semantics35 A while example i := 3; f := 1 ; while i do f := f * i ; i := i - 1 od    {i=3, f=3}and  {i=2, f=3}

36 Dec 16. 2003Formal Semantics36 A while example, cont.  {i=0, f=6} And we are finally done!

37 Dec 16. 2003Formal Semantics37 Implementing operational semantics An “executable specification” Gives us an interpreter Now we can test the language before we implement a real compiler Easily done in Prolog! 3 * (4 + 5) is represented as the fact: times(3, plus(4, 5)). a := 2 + 3 ; b:= a * 4 ; a := b - 5 becomes: seq (assign (a, plus(2, 3)), seq (assign (b, times (a, 4)), assign (a, sub (b, 5)))). This is actually a tree

38 Dec 16. 2003Formal Semantics38 Implementing operational semantics, cont. Reduction rule #3 could look like: reduce (plus(V1, V2), R) :- integer(V1), integer(V2), !, R in V1 + V2. Rule #7 becomes: reduce (plus (E, E2), plus (E1, E2)) :- reduce (E, E1). Lookup in an environment (rule 15): reduce (config (I, Env), config (V, Env)) :- atom (I), !, lookup (Env, I, V). Update an environment (rule 16): reduce (config (assign (I, V), Env), Env1) :- integer (V), !, update (Env, value (I, V), Env1).

39 Dec 16. 2003Formal Semantics39 Denotational semantics Now we will use functions to describe the semantics: Val: Expression  Integer So Val (2 + 3 * 4) should be 14 Val maps a syntactic domain (the set of correct arithmetic expressions) to a semantic domain (the set of integers) We need more function to cover the example language: P: Program  (Input  Output) Syntactic domain: The set of correct programs Semantic domain: The set of functions that gives us the correct answer from the possible inputs

40 Dec 16. 2003Formal Semantics40 Denotational semantics, cont. We need three parts –Definitions of the syntactic domains –Definitions of the semantic domains –Definitions of the semantic functions The syntactic domain looks almost like the abstract syntax: N  N D | D D  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 N: Number, D: Digit

41 Dec 16. 2003Formal Semantics41 The Semantic domain A set that contains all answers to possible inputs For the numbers, it’s just {0, 1, …} The integers with its operations could look like: Domain v: Integer = {…, -2, -1, 0, 1, 2, …} Operations: + :Integer x Integer  Integer - :Integer x Integer  Integer * :Integer x Integer  Integer

42 Dec 16. 2003Formal Semantics42 The Semantic function For each syntactic domain we need a semantic function, for example: D: Digit  Integer(defined by:) D[[0]] = 0, D[[1]] = 1, …, D[[9]] = 9 N: Number  Integer N[[ND]] = 10 * N[[N]] + N[[D]] N[[D]] = D[[D]]

43 Dec 16. 2003Formal Semantics43 Some more parts from the example The semantic functions for the arithmetics: E: Expression  Integer E[[E 1 + E 2 ]] = E[[E 1 ]] + E[[E 2 ]] E[[E 1 * E 2 ]] = E[[E 1 ]] * E[[E 2 ]] E[[( E )]] = E[[E]] E[[N]] = N[[N]] etc. The complete example in section 13.3.4-13.3.5

44 Dec 16. 2003Formal Semantics44 Environments The environments forms a new semantic domain Domain Env: Environment = Identifier  Integer  {undef} And expressions: E: Expression  (Environment  Integer┴ The identifier rule: E[[I]] (Env) = Env (I)

45 Dec 16. 2003Formal Semantics45 Statements Recall the syntactic domain: S  I := E | if E then L 1 else L 2 fi | while E do L od L: Statement list, S: Statement, E: Expression And the semantic domain is: S: Statement  Environment  Environment The semantic function for the if-statement: S [[if E then L 1 else L 2 fi]] (Env) = if E [[E]] (Env) > 0 then L[[L 1 ]](Env) else L[[L 2 ]](Env)

46 Dec 16. 2003Formal Semantics46 Implementation Denotational semantics fits very well into a functional programming language The abstract syntax may look like: data Expr = Val Int | Ident String | Plus Expr Expr | Minus Expr Expr | Times Expr Expr If we have implemented the environment with lookup and insert the evaluation function may look like: exprE :: Expr -> Environment -> Int exprE (Plus e1 e2) env = (exprE e1 env) + (exprE e2 env) exprE (Minus e1 e2) env = (exprE e1 env) - (exprE e2 env) exprE (Times e1 e2) env = (exprE e1 env) * (exprE e2 env) exprE (Val n) env = n exprE (Ident a) env = lookup env a

47 Dec 16. 2003Formal Semantics47 Axiomatic semantics The basis for mathematical proofs of programs We define what should be true before and after the program is evaluated (sometimes called assertions): x := x + 1 Precondition: {x = A} Postcondition: {x = A+1} This example works fine for all values A

48 Dec 16. 2003Formal Semantics48 Axiomatic semantics, cont. We have to make sure that A  0 {A  0, y=A} x := 1 / y {x = 1 / y} A sort example: {n≥1, if 1 ≤ i ≤ n then a [i] = A [i]} sort-program {sorted (a), permutation (a, A)}

49 Dec 16. 2003Formal Semantics49 Assertions Some languages have support for assertions, in C for example: #include … assert (y != 0) x = 1/y; … If y is 0 the program halts without executing the illegal division: Assertion failed at test.c line 27: y != 0 Exiting due to signal SIGABRT Throwing exceptions in Java also works

50 Dec 16. 2003Formal Semantics50 The weakest precondition If we think of a program and its pre/post conditions as: {P} C {Q} Then the weakest precondition (wp) is the one that is: –Strong enough as a precondition –Not stronger than any of the other possible preconditions Example: for C= 1/y, y>0 or y<0 is enough but y  0 is weaker, and strong enough One way to describe {P} C {Q} is: {P} C {Q} iff P  wp (C, Q)

51 Dec 16. 2003Formal Semantics51 Examples and properties of wp Some examples to get the idea: wp (“x:=1/y”, {x=1/y}) = {y  0} wp (“x:=x+1”, {x=A}) = {x=A-1} Some properties of wp: –Law of excluded miracle: wp (C, false) = false –Distributive laws: wp (C, P and Q) = wp (C, P) and wp (C, Q) wp (C, P) or wp (C, Q)  wp (C, P or Q) –Law of monotonicity: if Q  R then wp (C, P)  wp (C, R)

52 Dec 16. 2003Formal Semantics52 Use of wp in proofs So if we want to prove the correctness of a program C according to {P} C {Q} We have to prove that P  wp (C, Q) Very difficult for most programs! Useful if correctness is extremely important and difficult to test, example: –The micro code in a processor –Programs in space crafts, power plants, etc.


Download ppt "Dec 16. 2003Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI."

Similar presentations


Ads by Google