Formal semantics of loosely typed languages. Joep Verkoelen Vincent Driessen

Size: px
Start display at page:

Download "Formal semantics of loosely typed languages. Joep Verkoelen Vincent Driessen"

Transcription

1 Formal semantics of loosely typed languages Joep Verkoelen Vincent Driessen June, 2004

2 ii

3 Contents 1 Introduction 3 2 Syntax Formalities Example language LooselyWhile Semantics 7 4 The function Equals Rejected alternatives Accepted alternative Premises Functions needed Type hierarchy Definition of Equals Equivalence with While Formalities Proof A Casting values 25 A.1 Atomic casts A.2 The wrapper function Cast A.3 Casting to specific types B String conversions 27

4 2 CONTENTS

5 CHAPTER 1 Introduction In most programming languages, symbols are assigned a type either statically or dynamically. Statically assigning types to variables is quite simple and most commonly done by declaring a variable and specifying its type at the same time. With dynamical typed variables, the types of variables are unknown at the time of their declaration, but get known along the way. Loosely typed programming languages allow for much less restrictive declaration patterns. In fact, in PHP, you cannot even specify the type of a symbol. Symbols are considered to be of any type it can be interpreted as. For example, in PHP, you could say something like this: 1 function fib($n) { 2 if ($n <= 1) 3 return 1; 4 else 5 return $n * fib($n - 1); 6 } 7 8 $x = fib("10"); // $x holds the integer $x = substr($x, 0, 3); // $x now holds the string "362" In this small PHP script, before execution, the types of both the function fib and the variables $x and $n are yet unknown. When fib gets called for the first time (line 8), it is invoked with the string parameter "10", which implies that the variable $n will be of type string when entering the function body. However, in line 2, $n gets compared to 1, and PHP understands that we want to perform an integer comparison here. Therefore, it interprets the string "10" as the integer 10. Note, however, that $n is still a string. In line 3, the integer 1 is returned, so in that case the function fib returns an integer. Note that, in PHP, Functions may return different types depending on the execution path (although this does not happen in the above example).

6 4 Introduction In the first invocation of fib, we already saw that the variable $n is still a string. In line 5, something extraordinary happens: in execution of $n-1, $n again is interpreted as the integer 10, and subtracted by 1, resulting in a recursive call to fib, with the integer (!) 9 as the only argument. This means that in all subsequent recursive calls to fib, integers are used as arguments, instead of strings. Finally, we return to line 5 (in the first invocation of fib), which, because of the multiplication requires an interpretation of "10" as 10. The end result (the integer ) is stored in the variable $x (line 8). This variable is then used in the substr function (line 9) and because this (internal) PHP function requires the first argument to be a string, $x will be interpreted as such. The result of the substr call is a string containing the first three characters from the (interpreted) string $x. Finally, the result of this action (the string "362") is stored in the variable $x, which, until then, held an integer, but now contains a string. From this example, we can summarize PHP s behavior: 1. All variables have types. They get assigned their types the moment they get assigned their values. 2. Symbols are never fixed at a specific type. The type of symbols can change over time, namely at every new assignment. 3. Symbols can be always interpreted as other types, if the context requires it. Note that his does not affect the type of the symbol itself.

7 CHAPTER 2 Syntax Now that we have seen how loosely typed languages behave, we will introduce a way of describing syntax and semantics on a more abstract level, leaving out the creepy little details. Therefore, we will expand the toy language While, to the new language LooselyWhile. We assume that the reader is familiar with the language While. If not, it is advised to study [1]. 2.1 Formalities Before we introduce the syntax and semantics of LooselyWhile, we will first discuss some formalities that will be used throughout the rest of the document. Binary integers All numbers (integers) we use in LooselyWhile programs are required to be written in binary notation. This is to keep trivial definitions of a few functions short and surveyable. However, in our examples, we will use decimal notations for all integers. If one would want to explicitly define the definitions to use decimal notation, such a derivation from the currently used definition would be trivial. Strict seperation of expressions and statements Furthermore, we will assume that expressions have no side effects, as they can have in the case of PHP and many other programming languages simply since it is not our focus of research. This assumption, therefore, is purely made for the sake of simplicity. Also, this allows for a strict separation of statements and expressions. And it is exactly because of this that the types of variables are not affected when they are interpreted as another type (see the third note on the behavior of PHP in the previous chapter).

8 6 Syntax No undeclared variables In examples, we do not the use of variables before they are assigned a value. Although this is allowed in PHP variables are always initialized at some NULLvalue, we explicitly forbid it in LooselyWhile. After all, using unassigned variables makes no sense, anyway. 2.2 Example language LooselyWhile We will begin with defining the syntax for LooselyWhile. We will use a syntactic notation based on BNF. First we will list a number of meta-variables which will be used to range over syntactical categories. These meta-variables and categories are as follows: n will range over numerals, Num, b will range over booleans, Bool, w will range over strings, String, x will range over variables, Var, e will range over expressions, Exp, S will range over statements, Stm. The context-free grammar for LooselyWhile then looks as follows: n ::= 0 1 n 0 n 1 b ::= true false c ::= c alpha c num c whitespace c punctuation λ w ::= " c " p ::= p num p alpha λ x ::= alpha p e ::= n b w x e 1 e 2 e 1 + e 2 e 1 e 2 e 1 = e 2 e 1 e 2 e e 1 e 2 e 1 e 2 e e e 1 ++e. 2 e 1 e 2 e 1 = e2 S ::= x := e skip S 1 ; S 2 if e then S 1 else S 2 while e do S Where alpha, num, whitespace and punctuation are sets of characters. Furthermore there are some string operators head ( ), tail ( ), and concatenate (++) that describe the following behavior: Let s be a string. If s is empty, then s and s are both empty strings. Else, s is a string of length 1 with the first character of s, and s is the remainder of the string. For example: Let s = "foo", then s = "f" and s = "oo". Let s 1 and s 2 be strings. Then s 1 ++s 2 will be the concatenation of the two strings. For example: Let s 1 = "foo" and s 2 = "bar". Then s 1 ++s 2 = "foobar".

9 CHAPTER 3 Semantics The resulting semantics are described below. Most of this is rather straightforward. The only noticeable exception here is the definition of the = relation. The definition of the Equals() function is described in the next chapter. Table 3.1: Semantics of expressions in LooselyWhile N 0 = ( Int, 0 ) N 1 = ( Int, 1 ) N n 0 = ( Int, 2i ) where N n = ( Int, i ) N n 1 = ( Int, 2i + 1 ) where N n = ( Int, i ) B true = ( Bool, tt ) B false = ( Bool, ff ) S " c " = S c S c a = ( String, x 1,..., x n, a ) where S c = ( String, x 1,..., x n ) S c b = ( String, x 1,..., x n, b ) where S c = ( String, x 1,..., x n ).S c z = ( String, x 1,..., x n, z ) where S c = ( String, x 1,..., x n ) S c A = ( String, x 1,..., x n, A ) where S c = ( String, x 1,..., x n ) S c B = ( String, x 1,..., x n, B ) where S c = ( String, x 1,..., x n ).S c Z = ( String, x 1,..., x n, Z ) where S c = ( String, x 1,..., x n ) S c 0 = ( String, x 1,..., x n, 0 ) where S c = ( String, x 1,..., x n ) S c 1 = ( String, x 1,..., x n, 1 ) where S c = ( String, x 1,..., x n )..S λ = ( String, ) E n s = N n Continued on next page

10 8 Semantics E b s = B b E w s = S w E x s = s x Table 3.1: Semantics of expressions in LooselyWhile E e 1 e 2 s = ( Int, ToInt (E e 1 s) ToInt (E e 2 s) ) E e 1 + e 2 s = ( Int, ToInt (E e 1 s) + ToInt (E e 2 s) ) E e 1 e 2 s = ( Int, ToInt (E e 1 s) ToInt (E e 2 s) ) E e 1 = e 2 s = Equals { ( (E e 1 s, ) E e 2 s) Bool, tt if ToInt (E e E e 1 e 2 s = ( ) 1 s) ToInt (E e 2 s) Bool, ff if ToInt (E e 1 s) > ToInt (E e 2 s) { ( ) Bool, tt if ToBool (E e s) = ff E e s = ( ) Bool, { ( ff if) ToBool (E e s) = tt Bool, tt if ToBool (E e E e 1 e 2 s = ( ) 1 s) = tt and ToBool (E e 2 s) = tt { ( Bool, ff ) if ToBool (E e 1 s) = ff or ToBool (E e 2 s) = ff Bool, tt if ToBool (E e E e 1 e 2 s = ( ) 1 s) = tt or ToBool (E e 2 s) = tt Bool, ff if ToBool (E e 1 s) = ff and ToBool (E e 2 s) = ff E e s = ( String, head (ToString(E e s)) ) E e s = ( String, tail (ToString(E e s)) ) E e 1 ++e 2 s = ( String, concat (ToString(E e 1 s), ToString(E e 2 s)) ) { ( ) Bool, tt E e 1 e 2 s = ( ) ( Bool, ff ) Bool, tt. E e 1 = e2 s = ( ) Bool, ff if E e 1 s = E e 2 s if E e 1 s E e 2 s if t 1 = t 2 where E e 1 s = ( ) t 1, w 1 and E e 2 s = ( ) t 2, w 2 otherwise The functions ToInt, ToBool and ToString are further detailed in appendix A. The string-functions head, tail and concat are detailed in Appendix B.

11 9 The following table describes the natural semantics of all statements in LooselyWhile. [ass lw ] [skip lw ] [comp lw ] Table 3.2: Natural semantics of statements in LooselyWhile x := a, s s[x E a s] skip, s s S 1, s s S 2, s s S 1 ; S 2, s s [if tt lw ] S 1, s s if e then S 1 else S 2, s s [if ff lw] S 2, s s if e then S 1 else S 2, s s if ToBool (E e s) = tt if ToBool (E e s) = ff [while tt lw ] S, s s while e do S, s s while e do S, s s if ToBool (E e s) = tt [while ff lw ] while e do S, s s if ToBool (E e s) = ff

12 10 Semantics

13 CHAPTER 4 The function Equals There are multiple ways of defining the semantics of =. One essential thing about whatever implementation is chosen is that there will be some means of converting the types that get compared to either each other s type or both to some other type and then perform the actual comparison. 4.1 Rejected alternatives Right-to-left type reduction First, one can look at the type of the left argument and convert the right argument to that type, and do a comparison then. For instance, the expression: true = "true" In this interpretation, the first argument is of type Bool and this would mean that the second argument, the String would be converted to a Bool. However this can cause strange behavior. Consider the following expression: 5 = "5t" Using left-to-right type reduction, the string "5t" will be converted to an integer. This conversion could be done in multiple ways (which are mentioned in 4.5), but here it is chosen to scan the string for a numeric prefix, and use that as the integer value, which is the integer 5 in this case. Thus this would evaluate to tt, because the string "5t" would be converted to the integer 5. However, the expression: "5t" = 5 would evaluate to ff, because the integer 5 would be converted to the string "5".

14 12 The function Equals Left-to-right type reduction Likewise, left-to-right type reduction will leave us with the same problems as the right-to-left type reduction. Two-side type reduction Using two-side type reduction, we introduce one virtually universal data type to which both the left and the right hand arguments get converted, after which the comparison is performed within the universal data type domain. When using this, we should define a function Univ that converts the actual data type s value to a value in the universal domain. This approach, however, postpones all difficulties to the concrete implementation of the Univ function, because it is in that function that we need to ensure that, for example, both the integer 5, and the string "5", map to the same abstract object in the universal domain. This also means that the universal domain should be chosen in such a way that it is also possible to map all newly invented and introduced data types to this universal domain. Should this not be possible, then every time the language gets expanded with a new data type there is a risk that the universal domain should be adjusted, which in turn means that all casting from all existing types to this universal domain should also be adjusted. This kind of construct is a purely theoretical one, and doesn t allow for a concrete implementation, so we are not able to define semantics using such a mechanism in practice. 4.2 Accepted alternative Relative type reduction Relative type reduction can be used to convert either the left or the right side of the equation to the other side s type (or some lesser type that both sides can be converted to). Which of these conversions need to be performed depends on the types of the arguments and possibly by (one of) the values. How these conversion rules are defined, will be covered in more detail in the next sections. Furthermore, we will formally specify what is meant by a lesser type. 4.3 Premises Before we go into too much detail, we will set up some premises for the behavior of the =-relation. We believe that at all times, the =-relation should conform to these premises. Typically, we want to ensure the =-relation to be symmetric, in order to overcome strange behavior mentioned in section 4.1. Premise 1 (Symmetry). Let s be a state. Then, for all expressions e 1 and e 2 : E e 1 = e 2 s = E e 2 = e 1 s

15 4.4 Functions needed 13 One other problem that we came across was that in some definitions, a comparison with true and a comparison with false would give the same result. In general one would always expect these would give the opposite result if each other. This principle resulted in the following premise: Premise 2 (Opposites). Let s be a state. Then, for all expressions e, for all expressions e tt for which holds that E e tt s = ( Bool, tt ), and for all expressions e ff for which holds that E e ff s = ( Bool, ff ) goes: E e = e tt s = ( Bool, tt ) E e = e ff s = ( Bool, ff ) 4.4 Functions needed The string "false" is something you typically want to use as containing the boolean false. Similarly, you d want to use the string "5" as containing the integer 5. For this, we introduce two functions which determine whether a string is suited for usage as an integer or as a boolean. These functions are IsNumeric () and IsBoolean (), and they determine whether a string begins with a non-empty integer or boolean value. Their definitions are as follows: IsNumeric(S) := StartsWith(S, "0") StartsWith(S, "1") IsBoolean(S) := StartsWith(S, "true") StartsWith(S, "false") In order to make a good definition of the =-relation, we will define a number of functions and relations that will assist in making a solid definition. The first things we need to define are the elementary casting functions. These are functions that cast values of one type to another type. Because we currently have 3 types, there are 3 3 = 9 possible castings. For simplicity s sake, we will define a function Cast that takes 2 types as arguments and returns a function that casts values of the first type to values of the second type. The precise definition of this function can be read in appendix A. 4.5 Type hierarchy The type hierarchy itself is based on the amount of information a type can hold. Or more precise: The amount of information lost when converting to another type. This is best made clear with an example. For instance, consider the types Int and Bool. When a boolean is cast to an integer, no information will be lost, and the original boolean can be recovered by casting the integer back to a boolean. However, when an integer is cast to a boolean, a lot of information will be lost, and the original integer value cannot be recovered by casting back to an integer. This is because boolean has only 2 possible values, while there are countably many integer values. Because of this, the type Int is higher in the type hierarchy than the type Bool. In a similar fashion, we can see that the type String is higher in the type hierarchy than the type Int. Even though one could argue that one can always construct a lexicographical enumeration of strings and thus that there always is a means of casting back and forth between integers and strings, this would result in very odd string conversions and would certainly not be consistent

16 14 The function Equals with the way that strings are used in our example language LooselyWhile. Therefore, in LooselyWhile, we will consider String to be higher in the type hierarchy than Int. Definition 1. Let t 1 and t 2 be types. We will define the hierarchical ordering relation ( is a lesser type than ) to be: t 1 t 2 if and only if t 1 is lower in the type hierarchy than t 2. Using the Cast function, this results in the following formal definition: t 1 t 2 w1 [ Cast (t 2, t 1 ) (Cast (t 1, t 2 ) (w 1 )) = w 1 ] w2 [ Cast (t 1, t 2 ) (Cast (t 2, t 1 ) (w 2 )) = w 2 ] Where w 1 en w 2 are valid values of types t 1 and t 2, respectively (i.e. where the tuples ( t 1, w 1 ) and ( t2, w 2 ) are valid). 4.6 Definition of Equals Now that we have all these functions, we can finally put this together in the Equals function that we used in the semantics of the = operator. Equals (( ) ( )) t 1, w 1, t2, w 2 = Equals (( ) ( )) (Bool, t) 2, w 2, t1, w 1 if t 2 t 1 (Bool, tt ) if t 1 = t 2 and w 1 = w 2 ff if t 1 = t 2 and w 1 w 2 Equals (( ) ( t 1, w 1, Int, StringToInt(w2 ) )) if t 2 = String and IsNumeric(w 2 ) = tt Equals (( ) ( t 1, w 1, Bool, StringToBool(w2 ) )) if t 2 = Bool and IsBoolean(w 2 ) = tt Equals (( ) ( t 1, w 1, t1, Cast (t 2, t 1 ) (w 2 ) )) otherwise

17 CHAPTER 5 Equivalence with While LooselyWhile is an extension of the language While. This means that everything that can be expressed in the language While can be expressed in LooselyWhile as well. In fact, in this chapter, we will prove that every program in While syntax can be evaluated with LooselyWhile semantics and will yield a result that is equivalent to the result when evaluated with While semantics. Since LooselyWhile is an extension of While, all programs that are syntactically accepted in While are also accepted by LooselyWhile. We will show that the semantics of these programs remains equivalent. We use the term equivalent on purpose, because mathematically, the semantics of the two languages are not equal. In While, all variables are of the type integer, whereas in LooselyWhile they can be of non-integer types as well. Therefore, we have to use the type-data tuple representation for variables. As a consequence, states in LooselyWhile are affected and their definition differs slightly from the ones in While. Definition 2. Let s be a LooselyWhile-state. Then, like in While, s [y v] is the state s except that the value bound to y is v: { v if x = y (s [y v]) x = s x if x y The difference between the languages is that the v meta variable always holds an integer value in While, but a type-data tuple in LooselyWhile. This requires a notion to link the states. Definition 3. We say that a While-integer v and a LooselyWhile-integer v are equivalent if: v = ( Int, v ) We say that While-state is equivalent to a LooselyWhile-state if for all variables goes that the value of that variable in the While-state is equivalent to the value of the variable in the LooselyWhile-state. Formally:

18 16 Equivalence with While Definition 4. Let s be a While-state and s be a LooselyWhile-state. We say that s and s are equivalent if and only if s = LW (s), where LW is defined as follows: LW (s) = s x Var [ s x = ( Int, s x ) ] Now we are able to formulate our thesis. Thesis. For all statements S and all While-states s and s holds: If S, s s in While, then S, u u in LooselyWhile. where u and u are equivalent LooselyWhile-states: u = LW (s) and u = LW (s ). 5.1 Formalities In order to make the distinction between the semantic functions of While and LooselyWhile, we will transcribe the While-functions with the subscript While. For example, the semantic function A in While will become A While in the rest of the document. The LooselyWhile functions will keep their names, as defined in Table 3.1. When using the natural semantics rules, we will add the subscript w to the rule to indicate that the rule is from the natural semantics of While. This is more consistent with the subscript lw we have with the natural semantics rules of LooselyWhile. Throughout the rest of this document we will use u instead of LW (s), u instead of LW (s ), etc. This is done to improve the readability of the proofs. Finally, we will assume that While programs never use undeclared variables. 5.2 Proof To ease the proof of this thesis, we will introduce some lemmas. Lemma 1. At first, we will show that the BoolToBool and IntToInt casting functions are identity functions. Formally: 1. for all booleans b holds: BoolToBool(b) = b; and 2. for all integers x holds: IntToInt(x) = x Proof. This is trivial by the definitions of BoolToBool and IntToInt (see Appendix A). Lemma 2. For all n Num and all integers w holds: if N While n = w, then N n = ( Int, w ). Proof. We will prove this with induction on n: Base. We distinguish the following cases:

19 5.2 Proof 17 The case n = 0: We need to prove that if N While 0 = w, then N 0 = ( Int, w ). We have w = 0 by the definition of N While and N 0 = ( Int, 0 ) by the definition of N 0, in Table 3.1. Thus, in this case the lemma holds. The case n = 1: This is similar to the case n = 0 and we omit the details. Induction. The induction hypothesis is: for all integers w holds: if N While n = w, then N n = ( Int, w ) (Where n is a simpler case.) We distinguish the following cases: The case n = n 0: We need to prove that if N While n 0 = w, then N n 0 = ( Int, w ). We have w = 2 N While n = 2 w by the definition of N While and the induction hypothesis. Furthermore, we have N n 0 = ( Int, 2 i ) where N n = ( Int, i ) by Table 3.1. By the induction hypothesis, we have i = w, so N n 0 = ( Int, 2 w ). Thus, in this case the lemma holds. The case n = n 1: This is similar to the case n = n 0 and we omit the details. Thus, the lemma holds. Lemma 3. For all a Aexp, all integers w and all While-states s holds: if A While a s = w, then E a u = ( Int, w ) Proof. We will prove this with induction on a: Base. We distinguish the following cases: The case a = n: We need to prove that if A While n s = w, then E n u = ( Int, w ). We have A While n s = N While n by the definition of A While. Furthermore, we have E n u = N n by Table 3.1. Now we need to prove that if N While n = w, then N n = ( Int, w ). This is exactly Lemma 2. Thus, the lemma holds in this case. The case a = x: We need to prove that if A While x s = w, then E x u = ( Int, w ). We have A While x s = s x by the definition of A While. Furthermore, we have E x u = u x by Table 3.1. Now we need to prove that if s x = w then u x = ( Int, w ). We will assume that this holds (for more details on this, see the note).

20 18 Equivalence with While Thus the lemma holds in this case. NOTE: Actually we needed to prove that if s x = w then u x = ( Int, w ). But to prove this, we need to prove that if x := w, s s then x := w, u u. However, if we want to prove this, we must have a proof of that A While a s = w implies E a u = ( Int, w ), which is what we are proving now. This is provable, but this would make things too complex. The idea would be that we use the assumption that variables are only used after they are declared, and that thus we can point out an assignment (if there are any) where no other variables are used, and that this case of the lemma cannot occur. Then we can prove that the assignment of this variable in While is the same as the assignment of this variable in LooselyWhile. Then we can prove that, since variables are always declared before they are used, every assignment of a variable in While is the same as the assignment of this variable in LooselyWhile. And thus for all variables x holds: if s x = w then u x = ( Int, w ). Induction. The induction hypothesis is: for all integers w holds: if A While a s = w, then E a u = ( Int, w ) (Where a is a simpler case.) We distinguish the following cases: The case a = a 1 + a 2 : We need to prove that if A While a 1 + a 2 s = w, then E a 1 + a 2 u = ( Int, w ). Let w 1 = A While a 1 s and w 2 = A While a 2 s. We have A While a 1 + a 2 s = A While a 1 s + A While a 2 s = w 1 + w 2 by the definition of A While. Furthermore, we have E a 1 + a 2 u = ( Int, ToInt (E a 1 u) + ToInt (E a 2 u) ) by Table 3.1. By the induction hypothesis, we have E a 1 + a 2 u = ( Int, ToInt (( Int, w 1 )) + ToInt (( Int, w2 )) ) Thus, by the definition of ToInt (( Int, w )), we have E a 1 + a 2 u = ( Int, Cast (Int, Int) (w 1 ) + Cast (Int, Int) (w 2 ) ) Following the definition of Cast (Int, Int), this expands to E a 1 + a 2 u = ( Int, IntToInt(w 1 ) + IntToInt(w 2 ) )

21 5.2 Proof 19 Finally we have E a 1 + a 2 u = ( ) Int, w 1 + w 2 by Lemma 1. Thus, in this case the lemma holds. The case a = a 1 a 2 : This is similar to the case a = a 1 + a 2 and we omit the details. Thus, in this case, the lemma holds. The case a = a 1 a 2 : This is similar to the case a = a 1 + a 2 and we omit the details. Thus, the lemma holds. Lemma 4. For all b Bexp, all booleans w and all While-states s holds: if B While b s = w, then E b u = ( Bool, w ) Proof. We will prove this with induction on b: Base. We distinguish the following cases: The case b = true: We need to prove that if B While true s = w, then E true u = ( Bool, w ). We have w = tt by the definition of B While and E true u = ( Bool, tt ) by the definition of E true u. Thus, in this case, the lemma holds. The case b = false: This is similar to the case b = true and we omit the details. Thus, in this case, the lemma holds. The case b = a 1 = a 2 : We need to prove that if B While a 1 = a 2 s = w, then E a 1 = a 2 u = ( Bool, w ). From Lemma 3, we already have that if A While a 1 s = p, then E a 1 u = ( Int, p ) and if AWhile a 2 s = q, then E a 2 u = ( Int, q ). From the definition of B While, we have: { tt if p = q B While a 1 = a 2 s = ff if p q Furthermore, we have E a 1 = a 2 u = Equals (E a 1 u, E a 2 u), from Table 3.1. So we have E a 1 = a 2 u = Equals (( Int, p ), ( Int, q )). Because in this case t 1 = t 2 (Int = Int), the equation expands to: { ( ) Bool, tt if p = q E a 1 = a 2 u = ( ) Bool, ff if p q Thus, in this case, the lemma holds.

22 20 Equivalence with While The case b = a 1 a 2 : We need to prove that if B While a 1 a 2 s = w, then E a 1 a 2 u = ( Bool, w ). From Lemma 3, we already have that if A While a 1 s = p, then E a 1 u = ( Int, p ) and if AWhile a 2 s = q, then E a 2 u = ( Int, q ). From the definition of B While, we have: { tt if p q B While a 1 a 2 s = ff if p > q Furthermore, from Table 3.1, we have { ( ) Bool, tt if ToInt (E a E a 1 a 2 u = ( ) 1 u) ToInt (E a 2 u) Bool, ff if ToInt (E a 1 u) > ToInt (E a 2 u) From Lemma 3 we get: { ( ) Bool, tt E a 1 a 2 u = ( ) Bool, ff if ToInt (( Int, p )) ToInt (( Int, q )) if ToInt (( Int, p )) > ToInt (( Int, q )) From the definition of ToInt we get: { ( ) Bool, tt if Cast (Int, Int) (p) Cast (Int, Int) (q) E a 1 a 2 u = ( ) Bool, ff if Cast (Int, Int) (p) > Cast (Int, Int) (q) From the definition of Cast (Int, Int) we get: { ( ) Bool, tt if IntToInt(p) IntToInt(q) E a 1 a 2 u = ( ) Bool, ff if IntToInt(p) > IntToInt(q) Finally, by Lemma 1, we find: { ( ) Bool, tt E a 1 a 2 u = ( ) Bool, ff if p q if p > q Thus, in this case, the lemma holds. Induction. The induction hypothesis is: for all booleans w holds: if B While b s = w, then E b u = ( Bool, w ) (Where b is a simpler case.) We distinguish the following cases: The case b = b : We need to prove that if B While b s = w, then E b = ( Bool, w ). Let w = B While b s. From the definition of B While, we have: { B While b tt if w s = = ff ff if w = tt

23 5.2 Proof 21 Furthermore, from Table 3.1, we have: { ( ) E b Bool, tt if ToBool (E b u = ( ) u) = ff Bool, ff if ToBool (E b u) = tt Using the induction hypothesis, this expands to: { ( ) E b Bool, tt if ToBool (( Bool, w u = ( ) )) = ff Bool, ff if ToBool (( Bool, w )) = tt Through the Cast function, this leads to: { ( ) E b Bool, tt if BoolToBool(w u = ( ) ) = ff Bool, ff if BoolToBool(w ) = tt Using Lemma 1, we have: { ( ) E b Bool, tt u = ( ) Bool, ff if w = ff if w = tt And thus, in this case, the lemma holds. The case b = b 1 b 2 : We need to prove that if B While b 1 b 2 s = w, then E b 1 b 2 u = ( Bool, w ). Let w 1 = B While b 1 s and w 2 = B While b 2 s. From the definition of B While, we have: { tt if w1 = tt and w B While b 1 b 2 s = 2 = tt ff if w 1 = ff or w 2 = ff Furthermore, from Table 3.1, we have: ( ) Bool, tt if ToBool (E b 1 u) = tt E b 1 b 2 u = ( ) and ToBool (E b 2 u) = tt Bool, ff if ToBool (E b 1 u) = ff or ToBool (E b 2 u) = ff Using the induction hypothesis, this expands to: ( ) Bool, tt if ToBool (( )) Bool, w 1 = tt and ToBool (( )) Bool, w E b 1 b 2 u = ( ) 2 = tt Bool, ff if ToBool (( )) Bool, w 1 = ff or ToBool (( )) Bool, w 2 = ff Through the Cast function, this leads to: ( ) Bool, tt if BoolToBool(w 1 ) = tt E b 1 b 2 u = ( ) and BoolToBool(w 2 ) = tt Bool, ff if BoolToBool(w 1 ) = ff or BoolToBool(w 2 ) = ff Using Lemma 1, we have: { ( ) Bool, tt E b 1 b 2 u = ( ) Bool, ff if w 1 = tt and w 2 = tt if w 1 = ff or w 2 = ff And thus, in this case, the lemma holds.

24 22 Equivalence with While The case b = b 1 b 2 : This is similar to the case b = b 1 b 2 and we omit the details. Thus, the lemma holds. Proof of the thesis. We will prove this with induction on S. Base. We distinguish the following cases: The case S = skip: We need to prove that if skip, s s in While, then skip, u u in LooselyWhile. From the natural semantics of While we get that the only possible deduction rule is [skip w ]. From this rule we get: skip, s s Thus, s = s. From Table 3.2 we get that the only possible deduction rule is [skip lw ]. From this rule we get: skip, u u Thus, the thesis holds in this case. The case S = x := a: We need to prove that if x := a, s s in While, then x := a, u u in LooselyWhile. From the natural semantics of While we get that the only possible deduction rule is [ass w ]. From this rule we get: x := a, s s[x A While a s] Let w = A While a s, so we can write: x := a, s s[x w] From Table 3.2 we get that the only possible deduction rule is [ass lw ]. From this rule we get: x := a, u u[x E a u] From Lemma 3 we get: x := a, u u[x ( Int, w ) ] We can rewrite u (see section 5.1), so we get: x := a, LW (s) LW (s)[x ( Int, w ) ] From the definition of LW it is trivial to see that we get: x := a, LW (s) LW (s[x w]) Thus, the thesis holds in this case.

25 5.2 Proof 23 Induction. The induction hypothesis is: for all statements S, and all states s and s holds: If S, s s, then S, u u ( ) We distinguish the following cases: The case S = S 1 ; S 2 : We need to prove that if S 1 ; S 2, s s in While, then S 1 ; S 2, u u in LooselyWhile. Assume that S 1 ; S 2, s s in While. Now we need to prove that S 1 ; S 2, u u in LooselyWhile. From the natural semantics of While we get that the only possible deduction rule is [comp w ]. From this rule we get: S 1, s s and S 2, s s From the induction hypothesis and the above we get that in Loosely- While: S 1, u u and S 2, u u From Table 3.2 we get the rule [comp lw ] which says that because we have a deduction of S 1, u u and S 2, u u, we have a deduction of S 1 ; S 2, u u. Thus, the thesis holds in this case. The case S = if b then S 1 else S 2 : We need to prove that: If if b then S 1 else S 2, s s in While, then if b then S 1 else S 2, u u in LooselyWhile. We assume that if b then S 1 else S 2, s s in While. Now we need to prove that if b then S 1 else S 2, u u in LooselyWhile. We distinguish two cases: 1. B While b s = tt We need to prove that if if b then S 1 else S 2, s s in While then if b then S 1 else S 2, u u in LooselyWhile. From the natural semantics of While we get that the only possible deduction rule is [if tt w ]. From this we get S 1, s s. From Lemma 3 we get that E b u = ( Bool, tt ). From Table 3.2 we get that the only possible deduction rule for if b then S 1 else S 2, u is [if tt lw ]. This means that we need to prove that S 1, u u. We get this from the induction hypothesis. Thus, the thesis holds in this case. 2. B While b s = ff We need to prove that if if b then S 1 else S 2, s s in While then if b then S 1 else S 2, u u in LooselyWhile. From the natural semantics of While we get that the only possible deduction rule is [if ff w]. From this we get S 2, s s.

26 24 Equivalence with While From Lemma 3 we get that E b u = ( Bool, tt ). From Table 3.2 we get that the only possible deduction rule for if b then S 1 else S 2, u is [if ff lw ]. This means that we need to prove that S 2, u u. We get this from the induction hypothesis. Thus, the thesis holds in this case. The case S = while b do S : We need to prove that: If while b do S, s s in While, then while b do S, u u in LooselyWhile. We assume that while b do S, s s. while b do S, u u. We now need to prove that We will prove this by induction on the construction of the deduction tree of the while statement. Base. The last deduction rule used was [while ff w ]. From this rule we get that B While b s = ff and that s = s. Thus we need to prove that while b do S, u u. From Lemma 3 we get that E b u = ( Bool, ff ), thus the only possible deduction rule is [while ff lw ], which is exactly what we needed to prove. Thus, the thesis holds in this case. Induction. The induction hypothesis is that for smaller subtrees of the while statement, the thesis holds. Thus, for a certain s : If while b do S, s s, then while b do S, u u ( ) From the natural semantics of While we get that the only possible last step in the deduction tree of the while statement is [while tt w ], because the other possibility ([while ff w]) is covered in the base step of this induction. From this rule we get that B While b s = tt. We also get that there are subtrees of S, s s and while b do S, s s. From Table 3.2 we now get that the only possible deduction rule for while b do S, u is [while tt lw ]. From [while tt lw ] we get that if we can prove that there are subtrees for S, u u and while b do S, s u, we have proven that while b do S, u) u. S, u u follows from ( ). while b do S, u u follows from ( ). Thus, the thesis holds.

27 APPENDIX A Casting values To be able to cast values of a given type to any other given type, we need to introduce functions for every type to every other type that describe this cast. For readability s sake, we will introduce a wrapper function that returns the actual atomic cast function that performs the cast. A.1 Atomic casts The functions that perform (dumb) atomic casts are defined below: BoolToBool(b) = b{ 0 if b = true BoolToInt(b) = { 1 if b = false "true" if b = true BoolToString(b) = { "false" if b = false tt if x 0 IntToBool(x) = ff if x = 0 IntToInt(x) = x IntToString(x) = "0"IntToString( x "0" if x = 0 "1" if x = 1 2 ) if x 2 = 0 "1"IntToString( x 2 ) if x 2 = 1 tt if StartsWith(w, "true") StringToBool(w) = ff if StartsWith(w, "false") { ff otherwise GetIntFromString(w) if IsNumeric(w) = tt StringToInt(w) = 0 if IsNumeric(w) = ff StringToString(w) = w Here, the GetIntFromString(w) function returns the integer value of the longest head of the string w that is an integer. Working out these trivial

28 26 Casting values details to the finest would only decrease the readability. For example: GetIntFromString("701") = 701 GetIntFromString("12 or more") = 12 GetIntFromString("2 1 4") = 2 GetIntFromString("whatever") = 0 A.2 The wrapper function Cast The function Cast is trivial. It takes two types t 1 and t 2 as input and returns the atomic cast function that needs to be called for casting values of expressions of type t 1 to t 2 : Cast (t 1, t 2 ) = BoolToBool BoolToInt BoolToString IntToBool IntToInt IntToString StringToBool StringToInt StringToString if t 1 = Bool and t 2 = Bool if t 1 = Bool and t 2 = Int if t 1 = Bool and t 2 = String if t 1 = Int and t 2 = Bool if t 1 = Int and t 2 = Int if t 1 = Int and t 2 = String if t 1 = String and t 2 = Bool if t 1 = String and t 2 = Int if t 1 = String and t 2 = String A.3 Casting to specific types In the semantics described in chapter 3 the functions ToInt, ToBool and tostring are used. Now that we have a nice definition of the wrapper function Cast, these functions can (and will) be defined as follows: ToBool (( t, w )) ToInt (( t, w )) ToString (( t, w )) = Cast (t, Bool) (w) = Cast (t, Int) (w) = Cast (t, String) (w)

29 APPENDIX B String conversions Below are the definitions of a number of functions that were used in the definition of the semantics of LooselyWhile. These functions are head, tail and concat. head (s) = tail (s) = { if s = c 1 if s = c 1,..., c n { if s = c 2,..., c n if s = c 1,..., c n concat (s 1, s 2 ) = c 1,..., c n, k 1,..., k m where s 1 = c 1,..., c n and s 2 = k 1,..., k m

30 28 String conversions

31 Bibliography [1] Hanne Riis Nielson and Flemming Nielson. Semantics With Applications A Formal Introduction, 1999.

Formal Semantics of Programming Languages

Formal Semantics of Programming Languages Formal Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html Benefits of formal

More information

Formal Semantics of Programming Languages

Formal Semantics of Programming Languages Formal Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html Benefits of formal

More information

Semantics with Applications 3. More on Operational Semantics

Semantics with Applications 3. More on Operational Semantics Semantics with Applications 3. More on Operational Semantics Hanne Riis Nielson, Flemming Nielson (thanks to Henrik Pilegaard) [SwA] Hanne Riis Nielson, Flemming Nielson Semantics with Applications: An

More information

Programming Languages Third Edition

Programming Languages Third Edition Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand

More information

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m. CS 6110 S18 Lecture 8 Structural Operational Semantics and IMP Today we introduce a very simple imperative language, IMP, along with two systems of rules for evaluation called small-step and big-step semantics.

More information

3.7 Denotational Semantics

3.7 Denotational Semantics 3.7 Denotational Semantics Denotational semantics, also known as fixed-point semantics, associates to each programming language construct a well-defined and rigorously understood mathematical object. These

More information

Induction and Semantics in Dafny

Induction and Semantics in Dafny 15-414 Lecture 11 1 Instructor: Matt Fredrikson Induction and Semantics in Dafny TA: Ryan Wagner Encoding the syntax of Imp Recall the abstract syntax of Imp: a AExp ::= n Z x Var a 1 + a 2 b BExp ::=

More information

Semantics. A. Demers Jan This material is primarily from Ch. 2 of the text. We present an imperative

Semantics. A. Demers Jan This material is primarily from Ch. 2 of the text. We present an imperative CS411 Notes 1: IMP and Large Step Operational Semantics A. Demers 23-25 Jan 2001 This material is primarily from Ch. 2 of the text. We present an imperative language called IMP; wegive a formal definition

More information

Exercises on Semantics of Programming Languages

Exercises on Semantics of Programming Languages Technische Universität Wien SS 2014 Fakultät für Informatik Repetition sheet Assist. Prof. Florian Zuleger Tuesday, 8 April 2014 Assist. Prof. Georg Weissenbacher Univ. Prof. Agata Ciabattoni Moritz Sinn,

More information

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1 Natural Semantics Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1 1 Natural deduction is an instance of first-order logic; that is, it is the formal

More information

Mutable References. Chapter 1

Mutable References. Chapter 1 Chapter 1 Mutable References In the (typed or untyped) λ-calculus, or in pure functional languages, a variable is immutable in that once bound to a value as the result of a substitution, its contents never

More information

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Semantics via Syntax. f (4) = if define f (x) =2 x + 55. 1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)

More information

2 Introduction to operational semantics

2 Introduction to operational semantics 2 Introduction to operational semantics This chapter presents the syntax of a programming language, IMP, a small language of while programs. IMP is called an "imperative" language because program execution

More information

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions. CS 6110 S18 Lecture 18 Denotational Semantics 1 What is Denotational Semantics? So far we have looked at operational semantics involving rules for state transitions, definitional semantics involving translations

More information

Lecture Notes on Induction and Recursion

Lecture Notes on Induction and Recursion Lecture Notes on Induction and Recursion 15-317: Constructive Logic Frank Pfenning Lecture 7 September 19, 2017 1 Introduction At this point in the course we have developed a good formal understanding

More information

Handout 9: Imperative Programs and State

Handout 9: Imperative Programs and State 06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative

More information

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic 3.4 Deduction and Evaluation: Tools 3.4.1 Conditional-Equational Logic The general definition of a formal specification from above was based on the existence of a precisely defined semantics for the syntax

More information

Formal Semantics of Programming Languages

Formal Semantics of Programming Languages Formal Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html Benefits of formal

More information

CS103 Spring 2018 Mathematical Vocabulary

CS103 Spring 2018 Mathematical Vocabulary CS103 Spring 2018 Mathematical Vocabulary You keep using that word. I do not think it means what you think it means. - Inigo Montoya, from The Princess Bride Consider the humble while loop in most programming

More information

Program Analysis: Lecture 02 Page 1 of 32

Program Analysis: Lecture 02 Page 1 of 32 Program Analysis: Lecture 02 Page 1 of 32 Program Analysis/ Mooly Sagiv Lecture 1, 31/10/2012 Operational Semantics Notes by: Kalev Alpernas As background to the subject of Program Analysis, we will first

More information

CS422 - Programming Language Design

CS422 - Programming Language Design 1 CS422 - Programming Language Design From SOS to Rewriting Logic Definitions Grigore Roşu Department of Computer Science University of Illinois at Urbana-Champaign In this chapter we show how SOS language

More information

Computing Fundamentals 2 Introduction to CafeOBJ

Computing Fundamentals 2 Introduction to CafeOBJ Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal Faria, Prof. Heinrich Hußmann. See notes on slides

More information

Introduction to Denotational Semantics. Brutus Is An Honorable Man. Class Likes/Dislikes Survey. Dueling Semantics

Introduction to Denotational Semantics. Brutus Is An Honorable Man. Class Likes/Dislikes Survey. Dueling Semantics Brutus Is An Honorable Man HW2 will not be due today. Homework X+1 will never be due until after I have returned Homework X to you. Normally this is never an issue, but I was sick yesterday and was hosting

More information

Programming Languages 3. Definition and Proof by Induction

Programming Languages 3. Definition and Proof by Induction Programming Languages 3. Definition and Proof by Induction Shin-Cheng Mu Oct. 22, 2015 Total Functional Programming The next few lectures concerns inductive definitions and proofs of datatypes and programs.

More information

1 Lexical Considerations

1 Lexical Considerations Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2013 Handout Decaf Language Thursday, Feb 7 The project for the course is to write a compiler

More information

Lexical Considerations

Lexical Considerations Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Fall 2005 Handout 6 Decaf Language Wednesday, September 7 The project for the course is to write a

More information

Recursively Enumerable Languages, Turing Machines, and Decidability

Recursively Enumerable Languages, Turing Machines, and Decidability Recursively Enumerable Languages, Turing Machines, and Decidability 1 Problem Reduction: Basic Concepts and Analogies The concept of problem reduction is simple at a high level. You simply take an algorithm

More information

Consider a description of arithmetic. It includes two equations that define the structural types of digit and operator:

Consider a description of arithmetic. It includes two equations that define the structural types of digit and operator: Syntax A programming language consists of syntax, semantics, and pragmatics. We formalize syntax first, because only syntactically correct programs have semantics. A syntax definition of a language lists

More information

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules. Outline Type Checking General properties of type systems Types in programming languages Notation for type rules Logical rules of inference Common type rules 2 Static Checking Refers to the compile-time

More information

Big-step Operational Semantics Revisited

Big-step Operational Semantics Revisited Fundamenta Informaticae XXI (2001) 1001 1035 1001 IOS Press Big-step Operational Semantics Revisited Jarosław ominik Mateusz Kuśmierek Institute of Informatics Warsaw University, Poland jdk@google.com

More information

(Refer Slide Time: 4:00)

(Refer Slide Time: 4:00) Principles of Programming Languages Dr. S. Arun Kumar Department of Computer Science & Engineering Indian Institute of Technology, Delhi Lecture - 38 Meanings Let us look at abstracts namely functional

More information

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference Type Checking Outline General properties of type systems Types in programming languages Notation for type rules Logical rules of inference Common type rules 2 Static Checking Refers to the compile-time

More information

Formal Syntax and Semantics of Programming Languages

Formal Syntax and Semantics of Programming Languages Formal Syntax and Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html The While

More information

Chapter 3. The While programming language

Chapter 3. The While programming language Chapter 3 The While programming language 1 Contents 3 The While programming language 1 3.1 Big-step semantics........................... 2 3.2 Small-step semantics.......................... 9 3.3 Properties................................

More information

CS 4240: Compilers and Interpreters Project Phase 1: Scanner and Parser Due Date: October 4 th 2015 (11:59 pm) (via T-square)

CS 4240: Compilers and Interpreters Project Phase 1: Scanner and Parser Due Date: October 4 th 2015 (11:59 pm) (via T-square) CS 4240: Compilers and Interpreters Project Phase 1: Scanner and Parser Due Date: October 4 th 2015 (11:59 pm) (via T-square) Introduction This semester, through a project split into 3 phases, we are going

More information

(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1

(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1 CS 70 Discrete Mathematics for CS Fall 2000 Wagner MT1 Sol Solutions to Midterm 1 1. (16 pts.) Theorems and proofs (a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are

More information

Lexical Considerations

Lexical Considerations Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2010 Handout Decaf Language Tuesday, Feb 2 The project for the course is to write a compiler

More information

Mathematically Rigorous Software Design Review of mathematical prerequisites

Mathematically Rigorous Software Design Review of mathematical prerequisites Mathematically Rigorous Software Design 2002 September 27 Part 1: Boolean algebra 1. Define the Boolean functions and, or, not, implication ( ), equivalence ( ) and equals (=) by truth tables. 2. In an

More information

Introduction to Denotational Semantics. Class Likes/Dislikes Survey. Dueling Semantics. Denotational Semantics Learning Goals. You re On Jeopardy!

Introduction to Denotational Semantics. Class Likes/Dislikes Survey. Dueling Semantics. Denotational Semantics Learning Goals. You re On Jeopardy! Introduction to Denotational Semantics Class Likes/Dislikes Survey would change [the bijection question] to be one that still tested students' recollection of set theory but that didn't take as much time

More information

Formal Syntax and Semantics of Programming Languages

Formal Syntax and Semantics of Programming Languages Formal Syntax and Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html axioms

More information

LECTURE 16. Functional Programming

LECTURE 16. Functional Programming LECTURE 16 Functional Programming WHAT IS FUNCTIONAL PROGRAMMING? Functional programming defines the outputs of a program as a mathematical function of the inputs. Functional programming is a declarative

More information

Lecture Notes on Program Equivalence

Lecture Notes on Program Equivalence Lecture Notes on Program Equivalence 15-312: Foundations of Programming Languages Frank Pfenning Lecture 24 November 30, 2004 When are two programs equal? Without much reflection one might say that two

More information

Specifying Syntax. An English Grammar. Components of a Grammar. Language Specification. Types of Grammars. 1. Terminal symbols or terminals, Σ

Specifying Syntax. An English Grammar. Components of a Grammar. Language Specification. Types of Grammars. 1. Terminal symbols or terminals, Σ Specifying Syntax Language Specification Components of a Grammar 1. Terminal symbols or terminals, Σ Syntax Form of phrases Physical arrangement of symbols 2. Nonterminal symbols or syntactic categories,

More information

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages CMSC 330: Organization of Programming Languages Operational Semantics CMSC 330 Summer 2018 1 Formal Semantics of a Prog. Lang. Mathematical description of the meaning of programs written in that language

More information

Defining Functions. CSc 372. Comparative Programming Languages. 5 : Haskell Function Definitions. Department of Computer Science University of Arizona

Defining Functions. CSc 372. Comparative Programming Languages. 5 : Haskell Function Definitions. Department of Computer Science University of Arizona Defining Functions CSc 372 Comparative Programming Languages 5 : Haskell Function Definitions Department of Computer Science University of Arizona collberg@gmail.com When programming in a functional language

More information

Verification of Selection and Heap Sort Using Locales

Verification of Selection and Heap Sort Using Locales Verification of Selection and Heap Sort Using Locales Danijela Petrović September 19, 2015 Abstract Stepwise program refinement techniques can be used to simplify program verification. Programs are better

More information

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus Types Type checking What is a type? The notion varies from language to language Consensus A set of values A set of operations on those values Classes are one instantiation of the modern notion of type

More information

15 212: Principles of Programming. Some Notes on Induction

15 212: Principles of Programming. Some Notes on Induction 5 22: Principles of Programming Some Notes on Induction Michael Erdmann Spring 20 These notes provide a brief introduction to induction for proving properties of ML programs. We assume that the reader

More information

Summer 2017 Discussion 10: July 25, Introduction. 2 Primitives and Define

Summer 2017 Discussion 10: July 25, Introduction. 2 Primitives and Define CS 6A Scheme Summer 207 Discussion 0: July 25, 207 Introduction In the next part of the course, we will be working with the Scheme programming language. In addition to learning how to write Scheme programs,

More information

JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1)

JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1) Technology & Information Management Instructor: Michael Kremer, Ph.D. Class 2 Professional Program: Data Administration and Management JAVASCRIPT AND JQUERY: AN INTRODUCTION (WEB PROGRAMMING, X452.1) AGENDA

More information

Propositional Logic. Part I

Propositional Logic. Part I Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.

More information

The Worker/Wrapper Transformation

The Worker/Wrapper Transformation The Worker/Wrapper Transformation Andy Gill 1 Graham Hutton 2 1 The University of Kansas 2 The University of Nottingham March 26th, 2009 Andy Gill, Graham Hutton The Worker/Wrapper Transformation March

More information

Elementary Recursive Function Theory

Elementary Recursive Function Theory Chapter 6 Elementary Recursive Function Theory 6.1 Acceptable Indexings In a previous Section, we have exhibited a specific indexing of the partial recursive functions by encoding the RAM programs. Using

More information

Application: Programming Language Semantics

Application: Programming Language Semantics Chapter 8 Application: Programming Language Semantics Prof. Dr. K. Madlener: Specification and Verification in Higher Order Logic 527 Introduction to Programming Language Semantics Programming Language

More information

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End

More information

Functional Programming. Pure Functional Programming

Functional Programming. Pure Functional Programming Functional Programming Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends only on the values of its sub-expressions (if any).

More information

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011 CS152: Programming Languages Lecture 11 STLC Extensions and Related Topics Dan Grossman Spring 2011 Review e ::= λx. e x e e c v ::= λx. e c τ ::= int τ τ Γ ::= Γ, x : τ (λx. e) v e[v/x] e 1 e 1 e 1 e

More information

Language Reference Manual simplicity

Language Reference Manual simplicity Language Reference Manual simplicity Course: COMS S4115 Professor: Dr. Stephen Edwards TA: Graham Gobieski Date: July 20, 2016 Group members Rui Gu rg2970 Adam Hadar anh2130 Zachary Moffitt znm2104 Suzanna

More information

Fundamental Concepts. Chapter 1

Fundamental Concepts. Chapter 1 Chapter 1 Fundamental Concepts This book is about the mathematical foundations of programming, with a special attention on computing with infinite objects. How can mathematics help in programming? There

More information

CS4215 Programming Language Implementation. Martin Henz

CS4215 Programming Language Implementation. Martin Henz CS4215 Programming Language Implementation Martin Henz Thursday 26 January, 2012 2 Chapter 4 The Language simpl In this chapter, we are exting the language epl in order to provide a more powerful programming

More information

On Meaning Preservation of a Calculus of Records

On Meaning Preservation of a Calculus of Records On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract

More information

14.1 Encoding for different models of computation

14.1 Encoding for different models of computation Lecture 14 Decidable languages In the previous lecture we discussed some examples of encoding schemes, through which various objects can be represented by strings over a given alphabet. We will begin this

More information

Lecture 2: Big-Step Semantics

Lecture 2: Big-Step Semantics Lecture 2: Big-Step Semantics 1 Representing Abstract Syntax These are examples of arithmetic expressions: 2 * 4 1 + 2 + 3 5 * 4 * 2 1 + 2 * 3 We all know how to evaluate these expressions in our heads.

More information

CPS122 Lecture: From Python to Java last revised January 4, Objectives:

CPS122 Lecture: From Python to Java last revised January 4, Objectives: Objectives: CPS122 Lecture: From Python to Java last revised January 4, 2017 1. To introduce the notion of a compiled language 2. To introduce the notions of data type and a statically typed language 3.

More information

(Refer Slide Time: 00:51)

(Refer Slide Time: 00:51) Programming, Data Structures and Algorithms Prof. Shankar Balachandran Department of Computer Science and Engineering Indian Institute Technology, Madras Module 10 E Lecture 24 Content Example: factorial

More information

A macro- generator for ALGOL

A macro- generator for ALGOL A macro- generator for ALGOL byh.leroy Compagnie Bull-General Electric Paris, France INTRODUCfION The concept of macro-facility is ambiguous, when applied to higher level languages. For some authorsl,2,

More information

The University of Nottingham SCHOOL OF COMPUTER SCIENCE A LEVEL 4 MODULE, SPRING SEMESTER MATHEMATICAL FOUNDATIONS OF PROGRAMMING ANSWERS

The University of Nottingham SCHOOL OF COMPUTER SCIENCE A LEVEL 4 MODULE, SPRING SEMESTER MATHEMATICAL FOUNDATIONS OF PROGRAMMING ANSWERS The University of Nottingham SCHOOL OF COMPUTER SCIENCE A LEVEL 4 MODULE, SPRING SEMESTER 2012 2013 MATHEMATICAL FOUNDATIONS OF PROGRAMMING ANSWERS Time allowed TWO hours Candidates may complete the front

More information

7. Introduction to Denotational Semantics. Oscar Nierstrasz

7. Introduction to Denotational Semantics. Oscar Nierstrasz 7. Introduction to Denotational Semantics Oscar Nierstrasz Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues References > D. A. Schmidt, Denotational Semantics,

More information

Big-step Operational Semantics (aka Natural Semantics)

Big-step Operational Semantics (aka Natural Semantics) x = 1 let x = 1 in... x(1).!x(1) x.set(1) Programming Language Theory Big-step Operational Semantics (aka Natural Semantics) Ralf Lämmel A big-step operational semantics for While 2 This slide is derived

More information

CPS122 Lecture: From Python to Java

CPS122 Lecture: From Python to Java Objectives: CPS122 Lecture: From Python to Java last revised January 7, 2013 1. To introduce the notion of a compiled language 2. To introduce the notions of data type and a statically typed language 3.

More information

Reading 8 : Recursion

Reading 8 : Recursion CS/Math 40: Introduction to Discrete Mathematics Fall 015 Instructors: Beck Hasti, Gautam Prakriya Reading 8 : Recursion 8.1 Recursion Recursion in computer science and mathematics refers to the idea of

More information

Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5

Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5 Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5 [talking head] This lecture we study theory design and implementation. Programmers have two roles to play here. In one role, they

More information

Denotational semantics

Denotational semantics 1 Denotational semantics 2 What we're doing today We're looking at how to reason about the effect of a program by mapping it into mathematical objects Specifically, answering the question which function

More information

The Typed λ Calculus and Type Inferencing in ML

The Typed λ Calculus and Type Inferencing in ML Notes on Types S. Arun-Kumar Department of Computer Science and Engineering Indian Institute of Technology New Delhi, 110016 email: sak@cse.iitd.ernet.in April 14, 2002 2 Chapter 1 The Typed λ Calculus

More information

Semantics of COW. July Alex van Oostenrijk and Martijn van Beek

Semantics of COW. July Alex van Oostenrijk and Martijn van Beek Semantics of COW /; ;\ \\ // /{_\_/ `'\ \ (o) (o } / :--',-,'`@@@@@@@@ @@@@@@ \_ ` \ ;:( @@@@@@@@@ @@@ \ (o'o) :: ) @@@@ @@@@@@,'@@( `====' Moo! :: : @@@@@: @@@@ `@@@: :: \ @@@@@: @@@@@@@) ( '@@@' ;; /\

More information

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Design

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Design CONVENTIONAL EXECUTABLE SEMANTICS Grigore Rosu CS422 Programming Language Design Conventional Semantic Approaches A language designer should understand the existing design approaches, techniques and tools,

More information

The syntax and semantics of Beginning Student

The syntax and semantics of Beginning Student The syntax and semantics of Beginning Student Readings: HtDP, Intermezzo 1 (Section 8). We are covering the ideas of section 8, but not the parts of it dealing with section 6/7 material (which will come

More information

The syntax and semantics of Beginning Student

The syntax and semantics of Beginning Student The syntax and semantics of Beginning Student Readings: HtDP, Intermezzo 1 (Section 8). We are covering the ideas of section 8, but not the parts of it dealing with section 6/7 material (which will come

More information

Functional Programming Languages (FPL)

Functional Programming Languages (FPL) Functional Programming Languages (FPL) 1. Definitions... 2 2. Applications... 2 3. Examples... 3 4. FPL Characteristics:... 3 5. Lambda calculus (LC)... 4 6. Functions in FPLs... 7 7. Modern functional

More information

Programming Languages Fall 2013

Programming Languages Fall 2013 Programming Languages Fall 2013 Lecture 3: Induction Prof. Liang Huang huang@qc.cs.cuny.edu Recursive Data Types (trees) data Ast = ANum Integer APlus Ast Ast ATimes Ast Ast eval (ANum x) = x eval (ATimes

More information

Solutions to the Second Midterm Exam

Solutions to the Second Midterm Exam CS/Math 240: Intro to Discrete Math 3/27/2011 Instructor: Dieter van Melkebeek Solutions to the Second Midterm Exam Problem 1 This question deals with the following implementation of binary search. Function

More information

SCHEME 8. 1 Introduction. 2 Primitives COMPUTER SCIENCE 61A. March 23, 2017

SCHEME 8. 1 Introduction. 2 Primitives COMPUTER SCIENCE 61A. March 23, 2017 SCHEME 8 COMPUTER SCIENCE 61A March 2, 2017 1 Introduction In the next part of the course, we will be working with the Scheme programming language. In addition to learning how to write Scheme programs,

More information

Types and Static Type Checking (Introducing Micro-Haskell)

Types and Static Type Checking (Introducing Micro-Haskell) Types and Static (Introducing Micro-Haskell) Informatics 2A: Lecture 13 Alex Simpson School of Informatics University of Edinburgh als@inf.ed.ac.uk 16 October, 2012 1 / 21 1 Types 2 3 4 2 / 21 Thus far

More information

Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)

Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d) CMSC 330: Organization of Programming Languages Tail Calls A tail call is a function call that is the last thing a function does before it returns let add x y = x + y let f z = add z z (* tail call *)

More information

Week 5 Tutorial Structural Induction

Week 5 Tutorial Structural Induction Department of Computer Science, Australian National University COMP2600 / COMP6260 Formal Methods in Software Engineering Semester 2, 2016 Week 5 Tutorial Structural Induction You should hand in attempts

More information

Bootcamp. Christoph Thiele. Summer An example of a primitive universe

Bootcamp. Christoph Thiele. Summer An example of a primitive universe Bootcamp Christoph Thiele Summer 2012 0.1 An example of a primitive universe A primitive universe consists of primitive objects and primitive sets. This allows to form primitive statements as to which

More information

Information Theory and Coding Prof. S. N. Merchant Department of Electrical Engineering Indian Institute of Technology, Bombay

Information Theory and Coding Prof. S. N. Merchant Department of Electrical Engineering Indian Institute of Technology, Bombay Information Theory and Coding Prof. S. N. Merchant Department of Electrical Engineering Indian Institute of Technology, Bombay Lecture - 11 Coding Strategies and Introduction to Huffman Coding The Fundamental

More information

Graph Theory Questions from Past Papers

Graph Theory Questions from Past Papers Graph Theory Questions from Past Papers Bilkent University, Laurence Barker, 19 October 2017 Do not forget to justify your answers in terms which could be understood by people who know the background theory

More information

CMSC 330: Organization of Programming Languages. Operational Semantics

CMSC 330: Organization of Programming Languages. Operational Semantics CMSC 330: Organization of Programming Languages Operational Semantics Notes about Project 4, Parts 1 & 2 Still due today (7/2) Will not be graded until 7/11 (along with Part 3) You are strongly encouraged

More information

CSC312 Principles of Programming Languages : Functional Programming Language. Copyright 2006 The McGraw-Hill Companies, Inc.

CSC312 Principles of Programming Languages : Functional Programming Language. Copyright 2006 The McGraw-Hill Companies, Inc. CSC312 Principles of Programming Languages : Functional Programming Language Overview of Functional Languages They emerged in the 1960 s with Lisp Functional programming mirrors mathematical functions:

More information

In Our Last Exciting Episode

In Our Last Exciting Episode In Our Last Exciting Episode #1 Lessons From Model Checking To find bugs, we need specifications What are some good specifications? To convert a program into a model, we need predicates/invariants and

More information

IPCoreL. Phillip Duane Douglas, Jr. 11/3/2010

IPCoreL. Phillip Duane Douglas, Jr. 11/3/2010 IPCoreL Programming Language Reference Manual Phillip Duane Douglas, Jr. 11/3/2010 The IPCoreL Programming Language Reference Manual provides concise information about the grammar, syntax, semantics, and

More information

Maciej Sobieraj. Lecture 1

Maciej Sobieraj. Lecture 1 Maciej Sobieraj Lecture 1 Outline 1. Introduction to computer programming 2. Advanced flow control and data aggregates Your first program First we need to define our expectations for the program. They

More information

Introduction to the λ-calculus

Introduction to the λ-calculus Announcements Prelim #2 issues: o Problem 5 grading guide out shortly o Problem 3 (hashing) issues Will be on final! Friday RDZ office hours are 11-12 not 1:30-2:30 1 Introduction to the λ-calculus Today

More information

Meeting13:Denotations

Meeting13:Denotations Meeting13:Denotations Announcements Homework 3 due next week Friday at 6:00pm Homework2Comments Time: 29.2 hours avg Difficulty: 5.4 avg Issues Length? (Part 2 out Wed instead of Mon) Misunderstanding

More information

Objectives. Chapter 2: Basic Elements of C++ Introduction. Objectives (cont d.) A C++ Program (cont d.) A C++ Program

Objectives. Chapter 2: Basic Elements of C++ Introduction. Objectives (cont d.) A C++ Program (cont d.) A C++ Program Objectives Chapter 2: Basic Elements of C++ In this chapter, you will: Become familiar with functions, special symbols, and identifiers in C++ Explore simple data types Discover how a program evaluates

More information

Chapter 2: Basic Elements of C++

Chapter 2: Basic Elements of C++ Chapter 2: Basic Elements of C++ Objectives In this chapter, you will: Become familiar with functions, special symbols, and identifiers in C++ Explore simple data types Discover how a program evaluates

More information

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013 Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 1 Tuesday, January 29, 2013 1 Intro to semantics What is the meaning of a program? When we write a program, we use

More information

COP4020 Programming Assignment 1 - Spring 2011

COP4020 Programming Assignment 1 - Spring 2011 COP4020 Programming Assignment 1 - Spring 2011 In this programming assignment we design and implement a small imperative programming language Micro-PL. To execute Mirco-PL code we translate the code to

More information

1.3. Conditional expressions To express case distinctions like

1.3. Conditional expressions To express case distinctions like Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a

More information