Lecture 6: The Declarative Kernel Language Machine. September 13th, 2011

Size: px
Start display at page:

Download "Lecture 6: The Declarative Kernel Language Machine. September 13th, 2011"

Transcription

1 Lecture 6: The Declarative Kernel Language Machine September 13th, 2011

2 Lecture Outline Computations contd Execution of Non-Freezable Statements on the Abstract Machine The skip Statement The Sequential Composition Statement The local Statement The Variable-Variable Binding Statement The Value-Creation Statement Summary Execution of Freezable Statements on the Abstract Machine The if Statement The case Statement The Procedure Application Statement Oz Oz Implementing Oz in Oz Summary

3 Computations contd How does a computation proceed? Let statement 0 be a program. 1 The abstract machine is initialized as follows: 1. Create an empty environment: E 0 = {} 2. Create a semantic statement: s 0 = ( statement 0, E 0 ) 3. Create a semantic stack and push onto it the initial semantic statement: S 0 = [s 0 ] 4. Create an empty single assignment store: σ 0 = {} 5. Create the initial state of the abstract machine: M 0 = ( S 0, σ 0 ) 1 A program is a statement, possibly a sequence of statements recall the grammar for DSKL.

4 Computations contd How does a computation proceed? contd Start the machine in the initial execution state M 0 as described above. Use the following algorithm: 1. If in the current execution state, M i = ( S i, σ i ), the semantic stack S i is empty, stop and report success. 2. Otherwise, 2.1 take the first semantic statement, s i 1 = ( statement i 1, E i 1 ), from the stack; 2.2 execute statement i 1 using, if necessary, mappings from E i 1 and bindings from σ i ; 2.3 update the state of the semantic stack from S i to S i+1 by removing the topmost semantic statement (the one just executed) and pushing onto it new semantic statements if needed; 2.4 update the state of the single assignment store from σ i to σ i+1 by adding new variables and performing bindings, if needed; 2.5 in case of problems, stop and report failure. 3. Update the state of the machine from M i to M i+1 = ( S i+1, σ i+1 ), and go to 1.

5 Lecture Outline Computations contd Execution of Non-Freezable Statements on the Abstract Machine The skip Statement The Sequential Composition Statement The local Statement The Variable-Variable Binding Statement The Value-Creation Statement Summary Execution of Freezable Statements on the Abstract Machine The if Statement The case Statement The Procedure Application Statement Oz Oz Implementing Oz in Oz Summary

6 Execution of Non-Freezable Statements The skip statement Before: ( [s 1, s 2, s 3,...], σ ), s 1 = (skip, E 1 ) After: ( [s 2, s 3,...], σ ) Example (The skip statement) 1. ( [(skip, {})], {} ) 2. ( [], {} )

7 Execution of Non-Freezable Statements contd Sequential composition Before: ( [s 1, s 2, s 3,...], σ ) s 1 = ( statement 1.1 statement 1.2, E 1 ) After: ( [s 1.1, s 1.2, s 2, s 3,...], σ ) s 1.1 = ( statement 1.1, E 1 ) s 1.2 = ( statement 1.2, E 1 ) Example (Sequential composition) 1. ( [(skip skip, {})], {} ) 2. ( [(skip, {}), (skip, {})], {} )

8 Execution of Non-Freezable Statements contd Exercise Show how the computation proceeds if the state is: ( [(skip skip skip, E)], σ )

9 Execution of Non-Freezable Statements contd The local statement Before: ( [s 1, s 2, s 3,...], σ ) s 1 = (local id 1 in statement 1 end, E 1 ) After: ( [s 1, s 2, s 3,...], σ ) s 1 = ( statement 1, E 1 ) σ = σ {v} E 1 = E 1 + { id 1 v} v is a new, unbound variable (v / σ) Example (The local statement) 1. ( [(local X in skip end, {})], {} ) 2. ( [(skip, {X v 1 })], {v 1 } )

10 Execution of Non-Freezable Statements contd Variable-variable binding (naive version) Before: ( [s 1, s 2, s 3,...], σ ) s 1 = ( id 1 = id 2, E 1 ) After: ( [s 2, s 3,...], σ ) σ = σ {E 1 ( id 1 ) = E 1 ( id 2 )} The rule is fine if both E 1 ( id 1 ) and E 1 ( id 2 ) are unbound in σ: the variables are made equivalent, and both remain unbound in σ. Example (Variable-variable binding) 1. ( [(X = Y, {X v 1,Y v 2 })], {v 1, v 2 } ) 2. ( [], {v 1, v 2, v 1 = v 2 } )

11 Execution of Non-Freezable Statements contd Other situations are possible. Let v 1 = E 1 ( id 1 ) and v 2 = E 1 ( id 1 ); then: 1. If v 1 is unbound but v 2 is bound in σ: make v 1 equivalent to v 2, as above, or bind v 1 directly to the value of v If both v 1 and v 2 are bound, unify them, recursively if necessary: 2 perform additional bindings, if neeed; report a failure if, at any step in the recursive process, two values do not unify; otherwise, optionally make v 1 and v 2 equivalent in σ (logically useless, but may have practical effects). 3 Note: It is still unspecified what should happen if additional bindings are needed, and yet the values of v 1 and v 2 are nonunifiable. See Ch. 13 in CTMCP for more details on this issue. 2 Complex values (e.g., nested records) require unification to proceed recursively on their components. 3 E.g., next time v 1 and v 2 are compared there is no need to examine their content.

12 Execution of Non-Freezable Statements contd Example (Variable-variable binding) 1. ( [(X = Y, {X v 1,Y v 2 })], {v 1 = tree(leaf leaf), v 2 = tree(v 3 bird), v 3 } ) 2. ( [], {v 1 = tree(leaf leaf), v 2 = tree(leaf worm), v 3 = leaf} ) a unification failure is reported: leaf bird (but v 3 becomes bound). Note: If we allow additional bindings even if there is a unification failure, what bindings will actually be made depends on the order of unification of components in complex values. 4 Example (Variable-variable binding) 1. ( [(X = Y, {X v 1,Y v 2 })], {v 1 = tree(leaf leaf), v 2 = tree(bird v 3 ), v 3 } ) 2. ( [], {v 1 = tree(leaf leaf), v 2 = tree(bird v 3 ), v 3 } ) a unification failure is reported: leaf bird (and v 3 remains unbound). 4 If the semantics of the language do not make it clear, then it is an implementational detail.

13 Execution of Non-Freezable Statements contd Value creation (naive version) Before: ( [s 1, s 2, s 3,...], σ ) s 1 = ( id 1 = value 1, E 1 ) After: ( [s 2, s 3,...], σ ) σ = σ {E 1 ( id 1 ) = o} o is an object (a value) that results from an evaluation of the expression value 1 within the context of E 1 and σ. Note: The rule does not account for the more complex case where E 1 ( id ) is an already bound variable in such cases we perform unification, and the scheme is analogous to that for variable-variable binding of already bound variables. Example (Value creation) 1. ( [(X = tuple(y X), {X v 1,Y v 2 })], {v 1, v 2 } ) 2. ( [], {v 1 = tuple(v 2, v 1 ), v 2 } )

14 Execution of Non-Freezable Statements contd The semantics for value creation statements given in CTMCP differ slightly from the above: 1. a new, unbound variable (say, v x ) is created; 2. the value is actually created (the memory allocated and initialized), and v x is bound to the value; 3. the variable that id 1 is mapped to is bound to v x. Example (Value creation) 1. ( [(X = tuple(y X), {X v 1,Y v 2 })], {v 1, v 2 } ) 2. ( [], {v 1 = v x, v x = tuple(v 2, v 1 ), v 2 } ) The difference between these two variants is inessential, and we can safely adopt the earlier, more memory-efficient scheme.

15 Execution of Non-Freezable Statements contd Example (A simple kernel language program) local X in local Y in X = Y Y = true end end

16 Execution of Non-Freezable Statements contd Example (Execution of non-freezable statements contd) 1. ( [(local X in local Y in X=Y Y=true end end, {})], {} ) 2. ( [(local Y in X=Y Y=true end, {X v 1 })], {v 1 } ) 3. ( [(X=Y Y=true, {X v 1,Y v 2 })], {v 1, v 2 } ) 4. ( [(X=Y, {X v 1,Y v 2 }), (Y=true, {X v 1,Y v 2 })], {v 1, v 2 } ) 5. ( [(Y=true, {X v 1,Y v 2 })], {v 1, v 2, v 1 = v 2 } ) 6. ( [], {v 1 = true, v 2 = true, v 1 = v 2 } ) Note: Following CTMCP, the final state of the machine would look like ( [], {v 1 = v 3, v 2 = v 3, v 1 = v 2, v 3 = true} )

17 Execution of Non-Freezable Statements contd Value creation procedure values Before: ( [s 1, s 2, s 3,...], σ ) s 1 = ( id 1 = value 1, E 1 ) value 1 = proc {$ id p 1... id p n} statement p end id p 1,..., id p n are formal parameters After: ( [s 2, s 3,...], σ ) σ = σ {E 1 ( id 1 ) = c} c = (d c, E c ) is a closure (a procedure object, procedure value) a pair of a procedure definition d c and a closure environment E c d c corresponds, in some form, 5 to value 1 E c = E 1 { id c 1, id c 2,...}, where all id c i are free identifiers in statement 1 (identifiers in identifiers in statement 1 which are not in { id p 1,..., id p n}) 5 As the actual source code, as in CTMCP; as some intermediate internal form, e.g., a partial parse tree; or as compiled intermediate or target code.

18 Execution of Non-Freezable Statements contd Free identifiers An identifier is free in a statement if the statement does not declare it. Note: An identifier can have both free and bound (non-free) occurences in a statement. Example (Free identifiers) X is free in the following statements: local Y in Y = X + 1 end Y = proc {$ Z} Z = X + 1 end X is not free in the following statements: local X in X = Y + 1 end Y = proc {$ X} Z = X + 1 end X is both free and bound in the following statement: X = proc {$ X} Y = X + 1 end

19 Execution of Non-Freezable Statements contd Example (Procedure values) 1. ( [ (P = proc {$ A} A=B end, {P v 1,A v 2,B v 3 }) ], {v 1, v 2, v 3 } ) 2. ( [ ], {v 1 = (proc {$ A} A=B end, {B v 3 }), v 2, v 3 } ) Note: E c = E 1 {B} = {B v 3 } Example (Procedure values contd) 1. ( [ (P = proc {$ A} A=P end, {P v 1,A v 2,B v 3 }) ], {v 1, v 2, v 3 } ) 2. ( [ ], {v 1 = (proc {$ A} A = P end, {P v 1 }), v 2, v 3 } ) Note: E c = E 1 {P} = {P v 1 }

20 Execution of Non-Freezable Statements contd The skip statement, summary The semantic statement is: (skip, E) The execution rule is: Leave the rest of the stack and the store unchanged.

21 Execution of Non-Freezable Statements contd The sequence statement, summary The semantic statement is: ( statement 1 statement 2, E) The execution rule is: 1. Push ( statement 2, E) onto the stack. 2. Push ( statement 2, E) onto the stack. Leave the store unchanged.

22 Execution of Non-Freezable Statements contd The local statement, summary The semantic statement is: (local id in statement end, E) The execution rule is: 1. Allocate a new variable v i in the store. 2. Create E by adding the mapping id v i to E. 3. Push ( statement, E ) onto the stack.

23 Execution of Non-Freezable Statements contd The variable-variable binding statement, summary The semantic statement is: ( id 1 = id 2, E) The execution rule is: 1. Bind E( id 1 ) and E( id 2 ) in the store. 6 Leave the rest of the stack unchanged. 6 If both E( id 1 ) and E( id 1 ) are already bound, then their values must be unified. The result is either successful unification, or a runtime error.

24 Execution of Non-Freezable Statements contd The value-creation statement, summary The semantic statement is: The execution rule is: ( id = value, E) 1. Compute the value value of value. For any free identifier id in value, use E( id ) in the computation. 2. Bind E( id ) to value. 7 Leave the rest of the stack unchanged. 7 If E( id ) is already bound, its value must be unified with value. The result is either successful unification, or a runtime error.

25 Lecture Outline Computations contd Execution of Non-Freezable Statements on the Abstract Machine The skip Statement The Sequential Composition Statement The local Statement The Variable-Variable Binding Statement The Value-Creation Statement Summary Execution of Freezable Statements on the Abstract Machine The if Statement The case Statement The Procedure Application Statement Oz Oz Implementing Oz in Oz Summary

26 Execution of Freezable Statements contd The if statement The semantic statement is: The execution rule is: 1. Check E( id ). (if id then statement 1 else statement 2 end, E) If E( id ) is unbound, stop. If E( id ) is bound to true, push ( statement 1, E) on the stack. If E( id ) is bound to false, push ( statement 2,E) on the stack. Otherwise, raise an error. Leave the store unchanged.

27 Execution of Freezable Statements contd Example (The if statement) 1. ( [(if X then Y=1 else Y=2 end, {X v 1,Y v 2 })], {v 1 = true, v 2 } ) 2. ( [(Y=1, {X v 1,Y v 2 })], {v 1 = true, v 2 } ) 3. ( [], {v 1 = true, v 2 = 1} ) Example (The if statement) 1. ( [(if X then Y=1 else Y=2 end, {X v 1,Y v 2 })], {v 1, v 2 = 3} ) Note: The computation suspends, since E(X) is unbound. If the computation resumes, a unification failure is reported (but computation cannot resume in this model, we need concurrency).

28 Execution of Freezable Statements contd The case statement The semantic statement is: The execution rule is: 1. Check E( id 0 ). (case id 0 of literal ( feature 1 : id 1... feature n : id n ) then statement 1 else statement 2 end, E) If E( id 0 ) is unbound, stop. If E( id 0 ) is bound to a record with the label literal and arity of length n, containing exactly the features feature 1,..., feature n, then push onto the stack the semantic statement ( statement 1, E ), where E is created by adding to E the mapping id i E( id 0 ). feature i for i = 1,..., n. Otherwise, push ( statement 2, E) onto the stack. Leave the store unchanged.

29 Execution of Freezable Statements contd Example (The case statement) We shall examine step by step an execution of the following program: local X in local V in X = x(f:v) case X of x(f:x) then V = X % (1) else skip end end end (1) What is the content of X? What is the content of V? Is there a unification failure? Is this statement executed at all?

30 Execution of Freezable Statements contd Example (The case statement contd) 1. ( [(local X in... end, {})], {} ) 2. ( [(local V in... end, {X v 1 })], {v 1 } ) 3. ( [(X=x(f:V) case... end, {X v 1,V v 2 })], {v 1, v 2 } ) 4. ( [(X=x(f:V), {X v 1,V v 2 }),...], {v 1, v 2 } ) 5. ( [(case X of x(f:x)... end, {X v 1,V v 2 })], {v 1 = x(f:v 2 ), v 2 } ) 6. ( [(V=X, {X v 2,V v 2 })], {v 1 = x(f:v 2 ), v 2 } ) 7. ( [], {v 1 = x(f:v 2 ), v 2 } ) Note: Observe how the mapping for X changes from v 1 in (5) to v 2 in (6).

31 Execution of Freezable Statements contd The procedure application statement The semantic statement is: The execution rule is: 1. Check E( id 0 ). ({ id 0 id 1... id n }, E) If E( id 0 ) is unbound, stop. If E( id 0 ) is bound to a closure (p c,e c ) where the enclosed procedure definition has the form proc {$ id p 1... id p n} statement p end then push onto the stack the semantic statement ( statement p, E ), where E is created from E by adding the mapping id p i E( id i) for i = 1,..., n. Otherwise, raise an error. Leave the store unchanged. Note: This mechanism of passing arguments to procedures is typically called call by name or call by reference (the terminology is not consistent; we return to this issue later).

32 Execution of Freezable Statements contd Formal and actual parameters Formal parameter: An identifier in a procedure definition. Actual parameter: An identifier in a procedure application. Note: It is common to call formal parameters parameters, and actual parameters arguments. Example (Formal and actual parameters) P = proc {$ A B} A = B + 1 end {P X Y} A and B are formal parameters in a definition. X and Y are actual parameters in an application.

33 Execution of Freezable Statements contd Example (Procedure call) We shall examine step by step an execution of the following program: 8 local P in P = proc {$ X} local T in T = X == 0 if T then skip else local Y in Y = X - 1 {P Y} end end end end local Y in Y = 2 {P Y} end end 8 It s going to be boring, isn t it?

34 Execution of Freezable Statements contd Example (Procedure call contd) 1. ( [(local P in... end, {})], {} ) 2. ( [(P = proc {$ X}... end local X in... end, {P v 1 })], {v 1 } ) 3. ( [(P = proc {$ X}... end, {P v 1 }),...], {v 1 } ) 4. ( [(local Y in... end, {P v 1 })], {v 1 = (proc... end,{p v 1 })} ) 5. ( [(Y = 2 {P Y}, {P v 1,Y v 2 })], {v 1 = (...), v 2 } ) 6. ( [(Y = 2, {P v 1,Y v 2 }),...], {v 1 = (...), v 2 } ) 7. ( [({P Y}, {P v 1,Y v 2 })], {v 1 = (...), v 2 = 2} ) 8. ( [(local T in... end, {P v 1,X v 2 })], {v 1 = (...), v 2 = 2} ) 9. ( [(T = X == 0 if... end,{...,x v 2,T v 3 })], {..., v 2 = 2, v 3 } ) 10. ( [(T = X == 0,{...,X v 2,T v 3 }),...], {..., v 2 = 2, v 3 } ) 11. ( [(if T... end,{...,t v 3 })], {..., v 3 = false} ) 12. ( [(local Y in... end, {...})], {...} ) 13. homework: do the rest, try not to get lost...

35 The Abstract Kernel Language Machine Artificial intelligence meets natural stupidity. Drew McDermott Real stupidity beats artificial intelligence every time. Terry Pratchett

36 Lecture Outline Computations contd Execution of Non-Freezable Statements on the Abstract Machine The skip Statement The Sequential Composition Statement The local Statement The Variable-Variable Binding Statement The Value-Creation Statement Summary Execution of Freezable Statements on the Abstract Machine The if Statement The case Statement The Procedure Application Statement Oz Oz Implementing Oz in Oz Summary

37 Oz Oz Oz in Oz We have had a look at the Declarative Sequential Kernel Language (DSKL), a small subset of Oz: We have defined its syntax the form of source code constructs. We have defined its the meaning of programs in DSKL by means of a simple operational semantics rules for the execution of statements on an abstract machine. We have seen a few convenient syntactic shortcuts and linguistic abstractions that lead from the kernel language to a practical language. We have seen a few examples of use of the language, explained with handwaving semantics where necessary. We are now able to utilize this knowledge and build a metalinguistic abstraction: an interpreter for (a fragment of) Oz implemented in Oz.

38 Oz Oz Oz in Oz contd Interpretation To interpret a program given as source code, we need to 1. scan the code to produce a sequence of tokens; 9 2. parse the list of tokens to produce a parse tree; 3. process the parse tree, performing actions corresponding to its parts in the correct order. Here we shall implement only the last part (interpretation) assuming that we will have programs in an already parsed form. We can separately build a scanner and a parser (e.g., using the Gump tool) we shall return to this later. 10 Instead, we will play the role of a scanner and a parser, and hand-code parse trees not funny, but perfectly doable. 9 In practice, lexing and tokenizing are done in one pass over the code. 10 Please read if you re interested.

39 Oz Oz Oz in Oz contd How does the interpreter work? The interpreter is a procedure that takes as input a parse tree corresponding to a program; initializes the virtual machine; iteratively processes the input moving the machine from a state to a state. Note: Each state of the machine is completely specified by the content of its semantic stack and single assignment store. We will use the following template: fun {Interpret Program} fun {Iterate Stack Store}... end in {Iterate <initial stack> <initial store>} end

40 Oz Oz Oz in Oz contd Inside Interpret we define an internal function Iterate. The code above can be translated into a (semi)kernel form as follows: local Interpret in Interpret = proc {$ Program Result} local Iterate InitialStack InitialStore in 11 Iterate = proc {$ Stack Store Result}... end InitialStack =... InitialStore =... {Iterate InitialStack InitialStore Result} end end {Interpret Program} 12 end Note: We implement a subset of Oz in Oz, but the implementation language could be any other language C, Java, etc. 11 Multiple declaration not in the kernel language. 12 Program is a free identifier here.

41 Oz Oz Oz in Oz contd Representation Before we implement anything we need to settle: the encoding of parse trees; the structure of the semantic stack; the structure of the single assignment store. Parse trees are trees; we have already seen that trees can be easily encoded using nested records let s adopt this solution: Each parsed statement is a partial parse tree represented as a record. 13 Each parsed statement is of certain type, and may have some content. We can encode the type in the record s label. We can encode the content in the record s fields. 13 The whole program is parsed to a statement which is the complete parse tree.

42 Oz Oz Oz in Oz contd Example (Parse trees as nested records) This (trivial) program: skip can be (trivially) encoded as: skip Note: We need to quote the skip otherwise there would be a syntax error

43 Oz Oz Oz in Oz contd Example (Parse trees as nested records contd) This program: local X in local Y in X = Y Y = 2 end end can be encoded as: 14 loc(id: X stat:loc(id: Y stat:seq(1:uni(id: X val:id( Y )) 2:uni(id: Y val:int(2))))) Note: We need to quote the identifiers they are identifiers in the implemented language and should not be confused with identifiers in the implementation language. 14 The features 1, 2, etc. are optional, and we will omit them in further discussion.

44 Oz Oz Oz in Oz contd Example (Parse trees as nested records contd) This partial program: X = 1 Y = 2 Z = z(x:x y:y) can be encoded as: seq(uni(id: X val:int(1)) seq(uni(id: Y val:int(2)) uni(id: Z val:rec(lbl:z fts:[x y] ids:[ X Y ])))) Record values are encoded (in the parse tree) as records with fields named lbl, for storing the label, fts, for storing the features (as a list), ids, for storing the identifiers (as a list) used to create the record value in the program.

45 Oz Oz Oz in Oz contd We will assume that record value expressions are parsed so that the list of features is sorted lexicographically, and the list of identifiers is sorted in the corresponding order. Example (Record values) This record value expression: tree(right:x left:y) is parsed into this: rec(lbl:tree fts:[left right] ids:[ Y X ]) and not into any of these: rec(lbl:tree fts:[right left] ids:[ X Y ]) rec(lbl:tree fts:[left right] ids:[ X Y ])

46 Oz Oz Oz in Oz contd Example (Parse trees as nested records contd) This partial program: case X of label(feature:value) then Y = 1 else Y = 0 end can be encoded as: patm(id: X patt:rec(lbl:label fts:[feature] ids:[ Value ]) cons:uni(id: Y val:int(1)) alt:uni(id: Y val:int(0)))

47 Oz Oz Oz in Oz contd During execution of programs variables are kept in the single assignment store. We can represent variables the easy way: as Oz variables. 15 We can represent the store as a list of variables. An environment is a set of mappings from identifiers to variables. We can represent an environment as a list of identifier-variable index pairs. The identifiers correspond to the program code, and the indices corespond to the position of variables in the store-list. For simplicity, adding mappings to an environment is realized as adding them at the front of the list; a mapping placed earlier in an environment hides (shadows) mappings for the same identifier placed later in the same environment. 15 In case of a different implementation language, we might need to provide a complete implementation of dataflow variables from scratch.

48 Oz Oz Oz in Oz contd Example (Environments) The following list: [ X #1 Y #3 Var #7 X #2] represents an environment E, where: E = {X v 1,Y v 3,Var v 2 } Note: The mapping X v 2 is shadowed by the mapping X v 1, placed earlier in the environment list.

49 Oz Oz Oz in Oz contd Example (Single assignment store) The following list: [_ 1 record(feature:value)] represents the single assignment store σ with the following content: {v 1, v 2 = 1,v 3 = record(feature:value)} Note: An unbound variable in the implementation language represents an unbound variable in the implemented language.

50 Oz Oz Oz in Oz contd Semantic statements are pairs of (parsed) statements and environments. We can represent semantic statements as two-field records. Example (Semantic statements) The following record: semstat(stat:seq(uni(id: X val:int(1)) uni(id: X val:id( Y ))) env:[ X #1 Y #1]) represents the semantic statement s, where: s = (X = 1 X = Y, {X v 1,Y v 1 }) Note: Semantic statements are stored on the semantic stack. We can represent the semantic stack as a list of semantic statements.

51 Oz Oz Oz in Oz contd When we start the virtual machine with a (parsed) program, we create a new empty environment represented as the empty list; create a semantic statement containing the parsed statement and the initial environment; represent the initial semantic stack as a list containing the semantic statement; represent the initial single assignment store as the empty list.

52 Oz Oz Oz in Oz contd Example (States of the virtual machine) An execution of the following program: local X in X = 1 end starts in a state specified by: Stack = [semstat(stat:loc(id: X stat:uni(id: X val:int(1))) env:nil)] Store = nil and ends in a state specified by: Stack = nil Store = [1]

53 Oz Oz Oz in Oz contd How does Iterate work? Iterate tries to pop a semantic statement from the semantic stack by pattern matching, and then tests the parsed statement: fun {Iterate Stack Store} case Stack of semstat(stat:stat env:env) Stack then case Stat of... [] else error(stat) end else true end

54 Oz Oz Oz in Oz contd How does Iterate work? If there is a semantic statement on the stack, the semantic statement is decomposed into a statement and an environment, and the computation proceeds with the stack and store updated according to the content of the semantic statement. Otherwise (the stack is empty), there is nothing to do, and the computation has been completed and success is reported.

55 Oz Oz Oz in Oz contd Example (The skip statement) case Stat of skip then {Iterate Stack Store} If the statement is skip, there is nothing to do, and the computation proceeds with the rest of the stack and the store unchanged Note that after the initial pattern matching (case Stack...), the identifier Stack points to the rest of the stack, not including the just-popped skip.

56 Oz Oz Oz in Oz contd Example (The seq statement) case Stat... [] seq(stat1 Stat2) then {Iterate semstat(stat:stat1 env:env) semstat(stat:stat2 env:env) Stack Store} If the statement is a seq, the sequence statement is split into two parts which are pushed onto the stack with the same environment, and the computation proceeds with the store unchanged.

57 Oz Oz Oz in Oz contd Example (The loc statement) case Stat... [] loc(id:id stat:stat) then Index = {List.length Store} + 1 in {Iterate semstat(stat:stat env:(id#index) Env) Stack {List.append Store [_]}} If the statement is a loc, a new variable is appended to the store, and the statement inside the loc is pushed onto the stack with the environment extended with a mapping from the identifier to the variable.

58 Oz Oz Oz in Oz contd Try it! The file ozi.oz contains an implementation of the interpreter that supports a subset of DSKL except for procedure creation and application, arithmetics, etc. Load the file ozi-test.oz into the OPI and execute it. It will load the interpreter and execute a few test programs (statements are executed with some delay, to let you see how the computation proceeeds).... implement it in another language (Oz Java? Oz C++? Oz Ruby? Oz dc?)

59 Oz Oz Oz in Oz contd While implementing Oz in Oz, we made use of declarative variables included in the implementation language to implement declarative variables in the implemented language. How can we implement declarative variables in a language that does not have such a feature? The file code/oz/kernel/variable.java contains a naive implementation of dataflow variables (yes, in Java). 17 You can compile and try the code as follows: 18 $ javac oz/kernel/*.java $ java oz.kernel.test You can also test the compiled Java classes in, e.g., Jython or Scala as follows: 19 $ jython variable-test.jy $ scala variable-test.scala 17 Among other problems, the implementation is not thread safe which we can ignore for the moment, as we focus on sequential programming. 18 Or type make javac java. 19 Or type make jython or make scala.

60 Lecture Outline Computations contd Execution of Non-Freezable Statements on the Abstract Machine The skip Statement The Sequential Composition Statement The local Statement The Variable-Variable Binding Statement The Value-Creation Statement Summary Execution of Freezable Statements on the Abstract Machine The if Statement The case Statement The Procedure Application Statement Oz Oz Implementing Oz in Oz Summary

61 Summary This time Next time Homework Pensum Further reading Execution of statements on the DSKL abstract machine. Demonstration of an implementation of a subset of the DSKL machine. Memory management. Scope. Read Ch. 2 in CTMCP (focus on the semantic of the kernel language). All of today s slides, except for the implementation of Oz Oz. Ch. 4 from Structure and Interpretation of Computer Programs (SICP) by Abelson and Sussman shows how Scheme can be implemented in Scheme.

Lecture 5: Declarative Programming. The Declarative Kernel Language Machine. September 12th, 2011

Lecture 5: Declarative Programming. The Declarative Kernel Language Machine. September 12th, 2011 Lecture 5: Declarative Programming. The Declarative Kernel Language Machine September 12th, 2011 1 Lecture Outline Declarative Programming contd Dataflow Variables contd Expressions and Statements Functions

More information

Lecture 4: The Declarative Sequential Kernel Language. September 5th 2011

Lecture 4: The Declarative Sequential Kernel Language. September 5th 2011 Lecture 4: The Declarative Sequential Kernel Language September 5th 2011 1 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the

More information

Programming Language Concepts, cs2104 Lecture 04 ( )

Programming Language Concepts, cs2104 Lecture 04 ( ) Programming Language Concepts, cs2104 Lecture 04 (2003-08-29) Seif Haridi Department of Computer Science, NUS haridi@comp.nus.edu.sg 2003-09-05 S. Haridi, CS2104, L04 (slides: C. Schulte, S. Haridi) 1

More information

Lecture 21: Relational Programming II. November 15th, 2011

Lecture 21: Relational Programming II. November 15th, 2011 Lecture 21: Relational Programming II November 15th, 2011 Lecture Outline Relational Programming contd The Relational Model of Computation Programming with choice and Solve Search Strategies Relational

More information

Lecture 8: Recursion and Iteration. Exceptions. Declarative Programming.

Lecture 8: Recursion and Iteration. Exceptions. Declarative Programming. Lecture 8: Recursion and Iteration. Exceptions. Declarative Programming. September 26th, 2010 Lecture 8: Recursion and Iteration. Exceptions. Declarative Programming. (1/48) Lecture Outline Memory Management,

More information

On Academic Dishonesty. Declarative Computation Model. Single assignment store. Single assignment store (2) Single assignment store (3)

On Academic Dishonesty. Declarative Computation Model. Single assignment store. Single assignment store (2) Single assignment store (3) Declarative Computation Model Single assignment store (VRH 2.2) Kernel language syntax (VRH 2.3) Carlos Varela RPI October 6, 2009 Adapted with permission from: Seif Haridi KTH Peter Van Roy UCL On Academic

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

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far Outline Semantic Analysis The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Statically vs. Dynamically typed languages

More information

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou COMP-421 Compiler Design Presented by Dr Ioanna Dionysiou Administrative! Any questions about the syllabus?! Course Material available at www.cs.unic.ac.cy/ioanna! Next time reading assignment [ALSU07]

More information

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End Outline Semantic Analysis The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors

More information

Compiler Theory. (Semantic Analysis and Run-Time Environments)

Compiler Theory. (Semantic Analysis and Run-Time Environments) Compiler Theory (Semantic Analysis and Run-Time Environments) 005 Semantic Actions A compiler must do more than recognise whether a sentence belongs to the language of a grammar it must do something useful

More information

The role of semantic analysis in a compiler

The role of semantic analysis in a compiler Semantic Analysis Outline The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors

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

LECTURE 3. Compiler Phases

LECTURE 3. Compiler Phases LECTURE 3 Compiler Phases COMPILER PHASES Compilation of a program proceeds through a fixed series of phases. Each phase uses an (intermediate) form of the program produced by an earlier phase. Subsequent

More information

Operational Semantics. One-Slide Summary. Lecture Outline

Operational Semantics. One-Slide Summary. Lecture Outline Operational Semantics #1 One-Slide Summary Operational semantics are a precise way of specifying how to evaluate a program. A formal semantics tells you what each expression means. Meaning depends on context:

More information

Parsing Scheme (+ (* 2 3) 1) * 1

Parsing Scheme (+ (* 2 3) 1) * 1 Parsing Scheme + (+ (* 2 3) 1) * 1 2 3 Compiling Scheme frame + frame halt * 1 3 2 3 2 refer 1 apply * refer apply + Compiling Scheme make-return START make-test make-close make-assign make- pair? yes

More information

CS Lecture 2. The Front End. Lecture 2 Lexical Analysis

CS Lecture 2. The Front End. Lecture 2 Lexical Analysis CS 1622 Lecture 2 Lexical Analysis CS 1622 Lecture 2 1 Lecture 2 Review of last lecture and finish up overview The first compiler phase: lexical analysis Reading: Chapter 2 in text (by 1/18) CS 1622 Lecture

More information

6.184 Lecture 4. Interpretation. Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson

6.184 Lecture 4. Interpretation. Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson 6.184 Lecture 4 Interpretation Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson 1 Interpretation Parts of an interpreter Arithmetic calculator

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

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming Closures Mooly Sagiv Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming Summary 1. Predictive Parsing 2. Large Step Operational Semantics (Natural) 3. Small Step Operational Semantics

More information

Anatomy of a Compiler. Overview of Semantic Analysis. The Compiler So Far. Why a Separate Semantic Analysis?

Anatomy of a Compiler. Overview of Semantic Analysis. The Compiler So Far. Why a Separate Semantic Analysis? Anatomy of a Compiler Program (character stream) Lexical Analyzer (Scanner) Syntax Analyzer (Parser) Semantic Analysis Parse Tree Intermediate Code Generator Intermediate Code Optimizer Code Generator

More information

CS 11 Ocaml track: lecture 7

CS 11 Ocaml track: lecture 7 CS 11 Ocaml track: lecture 7 Today: Writing a computer language, part 2 Evaluating the AST Environments and scoping Where we're at We've implemented the first part of a language interpreter source code

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

COMPILER CONSTRUCTION LAB 2 THE SYMBOL TABLE. Tutorial 2 LABS. PHASES OF A COMPILER Source Program. Lab 2 Symbol table

COMPILER CONSTRUCTION LAB 2 THE SYMBOL TABLE. Tutorial 2 LABS. PHASES OF A COMPILER Source Program. Lab 2 Symbol table COMPILER CONSTRUCTION Lab 2 Symbol table LABS Lab 3 LR parsing and abstract syntax tree construction using ''bison' Lab 4 Semantic analysis (type checking) PHASES OF A COMPILER Source Program Lab 2 Symtab

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

Introduction to Scheme

Introduction to Scheme How do you describe them Introduction to Scheme Gul Agha CS 421 Fall 2006 A language is described by specifying its syntax and semantics Syntax: The rules for writing programs. We will use Context Free

More information

CS558 Programming Languages

CS558 Programming Languages CS558 Programming Languages Winter 2017 Lecture 7b Andrew Tolmach Portland State University 1994-2017 Values and Types We divide the universe of values according to types A type is a set of values and

More information

Declarative Computation Model

Declarative Computation Model Declarative Computation Model Kernel language semantics revisited (VRH 2.4.5) From kernel to practical language (VRH 2.6) Exceptions (VRH 2.7) Carlos Varela RPI March 19, 2012 Adapted with permission from:

More information

CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures. Dan Grossman Autumn 2018

CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures. Dan Grossman Autumn 2018 CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Autumn 2018 Typical workflow concrete syntax (string) "(fn x => x + x) 4" Parsing Possible errors / warnings

More information

Syntax Errors; Static Semantics

Syntax Errors; Static Semantics Dealing with Syntax Errors Syntax Errors; Static Semantics Lecture 14 (from notes by R. Bodik) One purpose of the parser is to filter out errors that show up in parsing Later stages should not have to

More information

UNIT 3

UNIT 3 UNIT 3 Presentation Outline Sequence control with expressions Conditional Statements, Loops Exception Handling Subprogram definition and activation Simple and Recursive Subprogram Subprogram Environment

More information

Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1

Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1 Static Semantics Lecture 15 (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1 Current Status Lexical analysis Produces tokens Detects & eliminates illegal tokens Parsing

More information

CPL 2016, week 10. Clojure functional core. Oleg Batrashev. April 11, Institute of Computer Science, Tartu, Estonia

CPL 2016, week 10. Clojure functional core. Oleg Batrashev. April 11, Institute of Computer Science, Tartu, Estonia CPL 2016, week 10 Clojure functional core Oleg Batrashev Institute of Computer Science, Tartu, Estonia April 11, 2016 Overview Today Clojure language core Next weeks Immutable data structures Clojure simple

More information

The Compiler So Far. CSC 4181 Compiler Construction. Semantic Analysis. Beyond Syntax. Goals of a Semantic Analyzer.

The Compiler So Far. CSC 4181 Compiler Construction. Semantic Analysis. Beyond Syntax. Goals of a Semantic Analyzer. The Compiler So Far CSC 4181 Compiler Construction Scanner - Lexical analysis Detects inputs with illegal tokens e.g.: main 5 (); Parser - Syntactic analysis Detects inputs with ill-formed parse trees

More information

CS 360 Programming Languages Interpreters

CS 360 Programming Languages Interpreters CS 360 Programming Languages Interpreters Implementing PLs Most of the course is learning fundamental concepts for using and understanding PLs. Syntax vs. semantics vs. idioms. Powerful constructs like

More information

Don t write anything in the field marked Eventuell ekstra ID. For each subtask, choose the answer you think is the most correct one.

Don t write anything in the field marked Eventuell ekstra ID. For each subtask, choose the answer you think is the most correct one. Contact persons under the exam: Per Holager, tlf 99 61 78 36 Ole Edsberg tlf 95 28 15 86 Language: English EXAM IN COURSE TDT4165 PROGRAMMING LANGUAGES Saturday May 15th, 2004, 0900 1300 No printed or

More information

MIDTERM EXAM (Solutions)

MIDTERM EXAM (Solutions) MIDTERM EXAM (Solutions) Total Score: 100, Max. Score: 83, Min. Score: 26, Avg. Score: 57.3 1. (10 pts.) List all major categories of programming languages, outline their definitive characteristics and

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

Project 2: Scheme Interpreter

Project 2: Scheme Interpreter Project 2: Scheme Interpreter CSC 4101, Fall 2017 Due: 12 November 2017 For this project, you will implement a simple Scheme interpreter in C++ or Java. Your interpreter should be able to handle the same

More information

flex is not a bad tool to use for doing modest text transformations and for programs that collect statistics on input.

flex is not a bad tool to use for doing modest text transformations and for programs that collect statistics on input. flex is not a bad tool to use for doing modest text transformations and for programs that collect statistics on input. More often than not, though, you ll want to use flex to generate a scanner that divides

More information

CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures

CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures Dan Grossman Fall 2014 Hi! I m not Hal J I love this stuff and have taught

More information

CS4215 Programming Language Implementation. Martin Henz

CS4215 Programming Language Implementation. Martin Henz CS4215 Programming Language Implementation Martin Henz Thursday 15 March, 2012 2 Chapter 11 impl: A Simple Imperative Language 11.1 Introduction So far, we considered only languages, in which an identifier

More information

Run-Time Data Structures

Run-Time Data Structures Run-Time Data Structures Static Structures For static structures, a fixed address is used throughout execution. This is the oldest and simplest memory organization. In current compilers, it is used for:

More information

Declarative concurrency. March 3, 2014

Declarative concurrency. March 3, 2014 March 3, 2014 (DP) what is declarativeness lists, trees iterative comutation recursive computation (DC) DP and DC in Haskell and other languages 2 / 32 Some quotes What is declarativeness? ness is important

More information

CS558 Programming Languages

CS558 Programming Languages CS558 Programming Languages Winter 2017 Lecture 4a Andrew Tolmach Portland State University 1994-2017 Semantics and Erroneous Programs Important part of language specification is distinguishing valid from

More information

EDAN65: Compilers, Lecture 06 A LR parsing. Görel Hedin Revised:

EDAN65: Compilers, Lecture 06 A LR parsing. Görel Hedin Revised: EDAN65: Compilers, Lecture 06 A LR parsing Görel Hedin Revised: 2017-09-11 This lecture Regular expressions Context-free grammar Attribute grammar Lexical analyzer (scanner) Syntactic analyzer (parser)

More information

Compiler Design 1. Bottom-UP Parsing. Goutam Biswas. Lect 6

Compiler Design 1. Bottom-UP Parsing. Goutam Biswas. Lect 6 Compiler Design 1 Bottom-UP Parsing Compiler Design 2 The Process The parse tree is built starting from the leaf nodes labeled by the terminals (tokens). The parser tries to discover appropriate reductions,

More information

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 11

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 11 CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 11 CS 536 Spring 2015 1 Handling Overloaded Declarations Two approaches are popular: 1. Create a single symbol table

More information

Compiler Construction

Compiler Construction Compiler Construction Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ss-16/cc/ Seminar Analysis and Verification of Pointer Programs (WS

More information

A Small Interpreted Language

A Small Interpreted Language A Small Interpreted Language What would you need to build a small computing language based on mathematical principles? The language should be simple, Turing equivalent (i.e.: it can compute anything that

More information

CA Compiler Construction

CA Compiler Construction CA4003 - Compiler Construction Semantic Analysis David Sinclair Semantic Actions A compiler has to do more than just recognise if a sequence of characters forms a valid sentence in the language. It must

More information

CSE 413 Languages & Implementation. Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341)

CSE 413 Languages & Implementation. Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341) CSE 413 Languages & Implementation Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341) 1 Goals Representing programs as data Racket structs as a better way to represent

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

News and remarks. CS68 Principles of Programming Languages. Contents today. Concurrency. Declarative concurrency. Threads

News and remarks. CS68 Principles of Programming Languages. Contents today. Concurrency. Declarative concurrency. Threads News and remarks CS68 Principles of Programming Languages Håkan Jonsson Dept of Computer Science and Electrical Engineering Luleå University of Technology, Sweden and Computer Science, Dartmouth College

More information

6.001 Notes: Section 15.1

6.001 Notes: Section 15.1 6.001 Notes: Section 15.1 Slide 15.1.1 Our goal over the next few lectures is to build an interpreter, which in a very basic sense is the ultimate in programming, since doing so will allow us to define

More information

The Compiler So Far. Lexical analysis Detects inputs with illegal tokens. Overview of Semantic Analysis

The Compiler So Far. Lexical analysis Detects inputs with illegal tokens. Overview of Semantic Analysis The Compiler So Far Overview of Semantic Analysis Adapted from Lectures by Profs. Alex Aiken and George Necula (UCB) Lexical analysis Detects inputs with illegal tokens Parsing Detects inputs with ill-formed

More information

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming Closures Mooly Sagiv Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming t ::= x x. t t t Call-by-value big-step Operational Semantics terms variable v ::= values abstraction x.

More information

1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.

1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 2. true / false ML can be compiled. 3. true / false FORTRAN can reasonably be considered

More information

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division Fall, 2001 Prof. R. Fateman SUGGESTED S CS 164 Final Examination: December 18, 2001, 8-11AM

More information

Compiler Construction

Compiler Construction Compiler Construction Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ss-17/cc/ Generation of Intermediate Code Outline of Lecture 15 Generation

More information

Procedures. EOPL3: Section 3.3 PROC and App B: SLLGEN

Procedures. EOPL3: Section 3.3 PROC and App B: SLLGEN Procedures EOPL3: Section 3.3 PROC and App B: SLLGEN The PROC language Expression ::= proc (Identifier) Expression AST: proc-exp (var body) Expression ::= (Expression Expression) AST: call-exp (rator rand)

More information

Programs as data first-order functional language type checking

Programs as data first-order functional language type checking Programs as data first-order functional language type checking Copyright 2013-18, Peter Sestoft and Cesare Tinelli. Created by Cesare Tinelli at the University of Iowa from notes originally developed by

More information

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore Lecture - 20 Intermediate code generation Part-4 Run-time environments

More information

COMPUTER SCIENCE TRIPOS

COMPUTER SCIENCE TRIPOS CST.2011.3.1 COMPUTER SCIENCE TRIPOS Part IB Monday 6 June 2011 1.30 to 4.30 COMPUTER SCIENCE Paper 3 Answer five questions. Submit the answers in five separate bundles, each with its own cover sheet.

More information

for (i=1; i<=100000; i++) { x = sqrt (y); // square root function cout << x+i << endl; }

for (i=1; i<=100000; i++) { x = sqrt (y); // square root function cout << x+i << endl; } Ex: The difference between Compiler and Interpreter The interpreter actually carries out the computations specified in the source program. In other words, the output of a compiler is a program, whereas

More information

6.037 Lecture 4. Interpretation. What is an interpreter? Why do we need an interpreter? Stages of an interpreter. Role of each part of the interpreter

6.037 Lecture 4. Interpretation. What is an interpreter? Why do we need an interpreter? Stages of an interpreter. Role of each part of the interpreter 6.037 Lecture 4 Interpretation Interpretation Parts of an interpreter Meta-circular Evaluator (Scheme-in-scheme!) A slight variation: dynamic scoping Original material by Eric Grimson Tweaked by Zev Benjamin,

More information

Declarative Programming Techniques

Declarative Programming Techniques Declarative Programming Techniques Declarativeness, iterative computation (CTM 3.1-3.2) Higher-order programming (CTM 3.6) Abstract data types (CTM 3.7) Carlos Varela Rensselaer Polytechnic Institute April

More information

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages CMSC 330: Organization of Programming Languages Type Systems, Names and Binding CMSC 330 - Spring 2013 1 Topics Covered Thus Far! Programming languages Ruby OCaml! Syntax specification Regular expressions

More information

Compiler Construction

Compiler Construction Compiler Construction Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ws-1819/cc/ Generation of Intermediate Code Outline of Lecture 15

More information

CS 406/534 Compiler Construction Putting It All Together

CS 406/534 Compiler Construction Putting It All Together CS 406/534 Compiler Construction Putting It All Together Prof. Li Xu Dept. of Computer Science UMass Lowell Fall 2004 Part of the course lecture notes are based on Prof. Keith Cooper, Prof. Ken Kennedy

More information

The PCAT Programming Language Reference Manual

The PCAT Programming Language Reference Manual The PCAT Programming Language Reference Manual Andrew Tolmach and Jingke Li Dept. of Computer Science Portland State University September 27, 1995 (revised October 15, 2002) 1 Introduction The PCAT language

More information

Sardar Vallabhbhai Patel Institute of Technology (SVIT), Vasad M.C.A. Department COSMOS LECTURE SERIES ( ) (ODD) Code Optimization

Sardar Vallabhbhai Patel Institute of Technology (SVIT), Vasad M.C.A. Department COSMOS LECTURE SERIES ( ) (ODD) Code Optimization Sardar Vallabhbhai Patel Institute of Technology (SVIT), Vasad M.C.A. Department COSMOS LECTURE SERIES (2018-19) (ODD) Code Optimization Prof. Jonita Roman Date: 30/06/2018 Time: 9:45 to 10:45 Venue: MCA

More information

Run-time Environments - 2

Run-time Environments - 2 Run-time Environments - 2 Y.N. Srikant Computer Science and Automation Indian Institute of Science Bangalore 560 012 NPTEL Course on Principles of Compiler Design Outline of the Lecture n What is run-time

More information

G Programming Languages Spring 2010 Lecture 4. Robert Grimm, New York University

G Programming Languages Spring 2010 Lecture 4. Robert Grimm, New York University G22.2110-001 Programming Languages Spring 2010 Lecture 4 Robert Grimm, New York University 1 Review Last week Control Structures Selection Loops 2 Outline Subprograms Calling Sequences Parameter Passing

More information

Declarative Concurrency (CTM 4)

Declarative Concurrency (CTM 4) Declarative Concurrency (CTM 4) Carlos Varela Rensselaer Polytechnic Institute Adapted with permission from: Seif Haridi KTH Peter Van Roy UCL November 21, 2014 C. Varela; Adapted with permission from

More information

The Environment Model. Nate Foster Spring 2018

The Environment Model. Nate Foster Spring 2018 The Environment Model Nate Foster Spring 2018 Review Previously in 3110: Interpreters: ASTs, evaluation, parsing Formal syntax: BNF Formal semantics: dynamic: small-step substitution model static semantics

More information

Compiling and Interpreting Programming. Overview of Compilers and Interpreters

Compiling and Interpreting Programming. Overview of Compilers and Interpreters Copyright R.A. van Engelen, FSU Department of Computer Science, 2000 Overview of Compilers and Interpreters Common compiler and interpreter configurations Virtual machines Integrated programming environments

More information

Typical workflow. CSE341: Programming Languages. Lecture 17 Implementing Languages Including Closures. Reality more complicated

Typical workflow. CSE341: Programming Languages. Lecture 17 Implementing Languages Including Closures. Reality more complicated Typical workflow concrete synta (string) "(fn => + ) 4" Parsing CSE341: Programming Languages abstract synta (tree) Lecture 17 Implementing Languages Including Closures Function Constant + 4 Var Var Type

More information

Programming Language Concepts, cs2104 Lecture 09 ( )

Programming Language Concepts, cs2104 Lecture 09 ( ) Programming Language Concepts, cs2104 Lecture 09 (2003-10-10) Seif Haridi Department of Computer Science, NUS haridi@comp.nus.edu.sg 2003-10-03 S. Haridi, CS2104, L09 (slides: C. Schulte, S. Haridi) 1

More information

CSE341, Spring 2013, Final Examination June 13, 2013

CSE341, Spring 2013, Final Examination June 13, 2013 CSE341, Spring 2013, Final Examination June 13, 2013 Please do not turn the page until 8:30. Rules: The exam is closed-book, closed-note, except for both sides of one 8.5x11in piece of paper. Please stop

More information

Lecture 15 CIS 341: COMPILERS

Lecture 15 CIS 341: COMPILERS Lecture 15 CIS 341: COMPILERS Announcements HW4: OAT v. 1.0 Parsing & basic code generation Due: March 28 th No lecture on Thursday, March 22 Dr. Z will be away Zdancewic CIS 341: Compilers 2 Adding Integers

More information

RYERSON POLYTECHNIC UNIVERSITY DEPARTMENT OF MATH, PHYSICS, AND COMPUTER SCIENCE CPS 710 FINAL EXAM FALL 96 INSTRUCTIONS

RYERSON POLYTECHNIC UNIVERSITY DEPARTMENT OF MATH, PHYSICS, AND COMPUTER SCIENCE CPS 710 FINAL EXAM FALL 96 INSTRUCTIONS RYERSON POLYTECHNIC UNIVERSITY DEPARTMENT OF MATH, PHYSICS, AND COMPUTER SCIENCE CPS 710 FINAL EXAM FALL 96 STUDENT ID: INSTRUCTIONS Please write your student ID on this page. Do not write it or your name

More information

CS 314 Principles of Programming Languages

CS 314 Principles of Programming Languages CS 314 Principles of Programming Languages Lecture 16: Functional Programming Zheng (Eddy Zhang Rutgers University April 2, 2018 Review: Computation Paradigms Functional: Composition of operations on data.

More information

Week - 03 Lecture - 18 Recursion. For the last lecture of this week, we will look at recursive functions. (Refer Slide Time: 00:05)

Week - 03 Lecture - 18 Recursion. For the last lecture of this week, we will look at recursive functions. (Refer Slide Time: 00:05) Programming, Data Structures and Algorithms in Python Prof. Madhavan Mukund Department of Computer Science and Engineering Indian Institute of Technology, Madras Week - 03 Lecture - 18 Recursion For the

More information

CS 415 Midterm Exam Spring 2002

CS 415 Midterm Exam Spring 2002 CS 415 Midterm Exam Spring 2002 Name KEY Email Address Student ID # Pledge: This exam is closed note, closed book. Good Luck! Score Fortran Algol 60 Compilation Names, Bindings, Scope Functional Programming

More information

Syntax-Directed Translation. Lecture 14

Syntax-Directed Translation. Lecture 14 Syntax-Directed Translation Lecture 14 (adapted from slides by R. Bodik) 9/27/2006 Prof. Hilfinger, Lecture 14 1 Motivation: parser as a translator syntax-directed translation stream of tokens parser ASTs,

More information

CSE450. Translation of Programming Languages. Lecture 11: Semantic Analysis: Types & Type Checking

CSE450. Translation of Programming Languages. Lecture 11: Semantic Analysis: Types & Type Checking CSE450 Translation of Programming Languages Lecture 11: Semantic Analysis: Types & Type Checking Structure Project 1 - of a Project 2 - Compiler Today! Project 3 - Source Language Lexical Analyzer Syntax

More information

The Structure of a Syntax-Directed Compiler

The Structure of a Syntax-Directed Compiler Source Program (Character Stream) Scanner Tokens Parser Abstract Syntax Tree Type Checker (AST) Decorated AST Translator Intermediate Representation Symbol Tables Optimizer (IR) IR Code Generator Target

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

Compiler Design (40-414)

Compiler Design (40-414) Compiler Design (40-414) Main Text Book: Compilers: Principles, Techniques & Tools, 2 nd ed., Aho, Lam, Sethi, and Ullman, 2007 Evaluation: Midterm Exam 35% Final Exam 35% Assignments and Quizzes 10% Project

More information

Tiny Compiler: Back End

Tiny Compiler: Back End CS 301 Spring 2016 January 29 Lab Tiny Compiler: Back End Plan Source Program Lexical Analysis Syntax Analysis Semantic Analysis Intermediate Code Generation Machine- Independent Optimization Code Generation

More information

5. Semantic Analysis!

5. Semantic Analysis! 5. Semantic Analysis! Prof. O. Nierstrasz! Thanks to Jens Palsberg and Tony Hosking for their kind permission to reuse and adapt the CS132 and CS502 lecture notes.! http://www.cs.ucla.edu/~palsberg/! http://www.cs.purdue.edu/homes/hosking/!

More information

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division. P. N. Hilfinger

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division. P. N. Hilfinger UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division CS 164 Spring 1999 P. N. Hilfinger CS 164: Final Examination Name: Login: Please do not discuss

More information

Draw a diagram of an empty circular queue and describe it to the reader.

Draw a diagram of an empty circular queue and describe it to the reader. 1020_1030_testquestions.text Wed Sep 10 10:40:46 2014 1 1983/84 COSC1020/30 Tests >>> The following was given to students. >>> Students can have a good idea of test questions by examining and trying the

More information

Problem with Scanning an Infix Expression

Problem with Scanning an Infix Expression Operator Notation Consider the infix expression (X Y) + (W U), with parentheses added to make the evaluation order perfectly obvious. This is an arithmetic expression written in standard form, called infix

More information

A Functional Evaluation Model

A Functional Evaluation Model A Functional Evaluation Model COS 326 Andrew W. Appel Princeton University slides copyright 2013-2015 David Walker and Andrew W. Appel A Functional Evaluation Model In order to be able to write a program,

More information

Semantic Analysis. Lecture 9. February 7, 2018

Semantic Analysis. Lecture 9. February 7, 2018 Semantic Analysis Lecture 9 February 7, 2018 Midterm 1 Compiler Stages 12 / 14 COOL Programming 10 / 12 Regular Languages 26 / 30 Context-free Languages 17 / 21 Parsing 20 / 23 Extra Credit 4 / 6 Average

More information

COMPILER CONSTRUCTION Seminar 02 TDDB44

COMPILER CONSTRUCTION Seminar 02 TDDB44 COMPILER CONSTRUCTION Seminar 02 TDDB44 Martin Sjölund (martin.sjolund@liu.se) Adrian Horga (adrian.horga@liu.se) Department of Computer and Information Science Linköping University LABS Lab 3 LR parsing

More information

Final Examination May 5, 2005

Final Examination May 5, 2005 CS 4352 Compilers and Interpreters Final Examination May 5, 2005 Name Closed Book. If you need more space ask for an extra sheet. 1. [4 points] Pick the appropriate data structure for each purpose: storage

More information

CS4215 Programming Language Implementation

CS4215 Programming Language Implementation CS4215 Programming Language Implementation You have 45 minutes to complete the exam. Use a B2 pencil to fill up the provided MCQ form. Leave Section A blank. Fill up Sections B and C. After finishing,

More information