C. Varela; Adapted w/permission from S. Haridi and P. Van Roy1 Declarative Computation Model Memory management, Exceptions, From kernel to practical language ( ) Carlos Varela RPI Adapted with permission from: Seif Haridi KTH Peter Van Roy UCL

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy2 From the kernel language to a practical language Interactive interface –the declare statement and the global environment Extend kernel syntax to give a full, practical syntax –nesting of partial values –implicit variable initialization –expressions –nesting the if and case statements –andthen and orelse operations Linguistic abstraction –functions

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy3 The interactive interface ( declare ) The interactive interface is a program that has a single global environment declare X Y Augments (and overrides) the environment with new mappings for X and Y {Browse X} Inspects the store and shows partial values, and incremental changes

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy4 The interactive interface ( declare ) Browse F X Y procedure value value a b Environment Store

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy5 declare X Y Browse F X Y procedure value value a b Environment Store unbound xixi x i+1

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy6 Syntactic extensions Nested partial values –person(name: “George” age:25) local A B in A= “George” B=25 person(name:A age:B) end Implicit variable initialization –local  pattern  =  expression  in  statement  end Example: assume T has been defined, then local tree(key:A left:B right:C value:D) = T in  statement  end is the same as: local A B C D in T = tree(key:A left:B right:C value:D) end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy7 Extracting fields in local statement declare T : T = tree(key:seif age:48 profession:professor) : local tree(key:A...) = T in  statement  end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy8 Nested if and case statements Observe a pair notation is: 1 # 2, is the tuple ‘#’(1 2) case Xs # Ys of nil # Ys then  s  1 []Xs # nil then  s  2 [](X|Xr) # (Y|Yr) andthen X=<Y then  s  3 else  s  4 end Is translated into case Xs of nil then  s  1 else case Ys of nil then  s  2 else case Xs of X|Xr then case Ys of Y|Yr then if X=<Y then  s  3 else  s  4 end else  s  4 end else  s  4 end end end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy9 Expressions An expression is a sequence of operations that returns a value A statement is a sequence of operations that does not return a value. Its effect is on the store, or outside of the system (e.g. read/write a file) 11*11X=11*11 expression statement

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy10 Functions as linguistic abstraction {F X1... Xn R} R = {F X1... Xn} fun {F X1... Xn}  statement   expression  end  statement  proc {F X1... Xn R}  statement  R =  expression  end  statement 

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy11 Nesting in data structures Ys = {F X}|{Map Yr F} Is unnested to: local Y Yr in Ys = Y|Yr {F X Y} {Map Xr F Yr} end The unnesting of the calls occurs after the data structure

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy12 Functional nesting Nested notations that allows expressions as well as statements local R in {F X1... Xn R} {Q R...} end Is written as (equivalent to): {Q {F X1... Xn}...} expression statement

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy13 Conditional expressions R = if  expr  1 then  expr  2 else  expr  3 end  expression   statement  if  expr  1 then R =  expr  2 else R =  expr  3 end fun {Max X Y} if X>=Y then X else Y end end proc {Max X Y R} R = ( if X>=Y then X else Y end ) end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy14 Example fun {Max X Y} if X>=Y then X else Y end end proc {Max X Y R} R = ( if X>=Y then X else Y end ) end proc {Max X Y R} if X>=Y then R = X else R = Y end end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy15 andthen and orelse  expr  1 andthen  expr  2 if  expr  1 then  expr  2 else false end  expr  1 orelse  expr  2 if  expr  1 then true else  expr  2 end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy16 Function calls {F1 {F2 X} {F3 Y}} local R1 R2 in R1 = {F2 X} R2 = {F3 Y} {F1 R1 R2} end Observe The arguments of a function are evaluated first from left to right

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy17 A complete example fun {Map Xs F} case Xs of nil then nil [] X|Xr then {F X}|{Map Xr F} end end proc {Map Xs F Ys} case Xs of nil then Ys = nil [] X|Xr then Y Yr in Ys = Y|Yr {F X Y} {Map Xr F Yr} end end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy18 Back to semantics Efficient loops in the declarative model –recursion used for looping –is efficient because of last call optimization –memory management and garbage collection Exceptions Functional programming

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy19 Last call optimization Consider the following procedure proc {Loop10 I} if I ==10 then skip else {Browse I} {Loop10 I+1} end end This procedure does not increase the size of the STACK It behaves like a looping construct

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy20 Last call optimization proc {Loop10 I} if I ==10 then skip else {Browse I} {Loop10 I+1} end end ST: [ ({Loop10 0}, E 0 ) ] ST: [({Browse I}, {I  i 0,...}) ({Loop10 I+1}, {I  i 0,...}) ]  : {i 0 =0,...} ST: [({Loop10 I+1}, {I  i 0,...}) ]  : {i 0 =0,...} ST: [({Browse I}, {I  i 1,...}) ({Loop10 I+1}, {I  i 1,...}) ]  : {i 0 =0, i 1 =1,...}

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy21 Garbage collection proc {Loop10 I} if I ==10 then skip else {Browse I} {Loop10 I+1} end end ST: [({Browse I}, {I  i k,...}) ({Loop10 I+1}, {I  i k,...}) ]  : {i 0 =0, i 1 =1,..., i k-i =k-1, i k =k,... } Garbage collection is an algorithm (a task) that removes from memory (store) all cells that are not accessible from the stack ST: [({Browse I}, {I  i k,...}) ({Loop10 I+1}, {I  i k,...}) ]  : { i k =k,... }

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy22 The memory use cycle Active memory is what the program needs to continue execution (semantic stack + reachable part of store) Memory that is no longer needed is of two kinds: –Can be immediately deallocated (i.e., semantic stack) –Simply becomes inactive (i.e., store) Reclaiming inactive memory is the hardest part of memory management –Garbage collection is automatic reclaiming ActiveFree Inactive Allocate/ deallocate Become inactive (program execution) Reclaim (garbage collection)

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy23 The Mozart Garbage Collector Copying dual-space algorithm Advantage : Execution time is proportional to the active memory size Disadvantage : Half of the total memory is unusable at any given time

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy24 Exceptions How to handle exceptional situations in the program? Examples: –divide by 0 –opening a nonexistent file Some errors are programming errors Some errors are imposed by the external environment Exception handling statements allow programs to handle and recover from errors

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy25 Exceptions Exception handling statements allow programs to handle and recover from errors The error confinement principle: –Define your program as a structured layers of components –Errors are visible only internally and a recovery procedure corrects the errors: either errors are not visible at the component boundary or are reported (nicely) to a higher level In one operation, exit from arbitrary depth of nested contexts –Essential for program structuring; else programs get complicated (use boolean variables everywhere, etc.)

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy26 Basic concepts A program that encounters an error (exception) should transfer execution to another part, the exception handler and give it a (partial) value that describes the error try  s  1 catch  x  then  s  2 end raise  x  end Introduce an exception marker on the semantic stack The execution is equivalent to  s  1 if it executes without raising an error Otherwise,  s  1 is aborted and the stack is popped up to the marker, the error value is transferred through  x , and  s  2 is executed

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy27 Exceptions (Example) fun {Eval E} if {IsNumber E} then E else case E of plus(X Y) then {Eval X}+{Eval Y} [] times(X Y) then {Eval X}*{Eval Y} else raise illFormedExpression(E) end end end end plus times5 6 4

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy28 Exceptions (Example) try {Browse {Eval plus(5 6) }} {Browse {Eval plus(times(5 5) 6) }} {Browse {Eval plus(minus(5 5) 6) }} catch illFormedExpression(E) then {System.showInfo ”**** illegal expresion ****” # E} end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy29 Try semantics The semantic statement is ( try  s  1 catch  y  then  s  2 end, E) Push the semantic statement ( catch  y  then  s  2 end, E) on ST Push (  s  1, E) on ST Continue to next execution step

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy30 Raise semantics The semantic statement is ( raise  x  end, E) Pop elements off ST looking for a catch statement: –If a catch statement is found, pop it from the stack –If the stack is emptied and no catch is found, then stop execution with the error message ”Uncaught exception” Let ( catch  y  then  s  end, E c ) be the catch statement that is found Push (  s , E c +{  E( )}) on ST Continue to next execution step

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy31 Catch semantics The semantic statement is ( catch  x  then  s  end, E) Continue to next execution step (like skip )

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy32 Full exception syntax Exception statements (expressions) with multiple patterns and finally clause Example: : FH = {OpenFile ”xxxxx”} : try {ProcessFile FH} catch X then {System.showInfo ”***** Exception when processing *****” # X} finally {CloseFile FH} end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy33 Strictly functional Restrict the language to make the language functional (I.e.without dataflow variables) –Language similar to Scheme (dynamically typed functional language) This is done by disallowing variable declaration (without initialization) and disallowing procedural syntax –Only use implicit variable initialization –Only use functions

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy34 Exercises What do you expect to happen if you try to execute the following statement? Try to answer without actually executing it! local T = tree(key:A left:B right:C value:D) in A = 1 B = 2 C = 3 D = 4 end

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy35 Exercise Here is a construct that uses some syntactic sugar : local T in local tree(left:A right:B) = T in end Here is an attempt to write the same construct using kernel language syntax and assuming there is an AssignLabel operation in Oz : local T in local A B in {AssignLabel T tree} T.right = B T.left = A end Are the above constructs always equivalent? Can you find a case when they are not? If not, how will you justify your belief that they are equivalent?

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy36 Exercise Suppose that A and B are predefined variables and Func1 is a predefined one argument function. Here is a construct that uses some syntactic sugar: local T in tree(left:{Func1 A} right:{Func1 B}) = T end Here is an attempt to write the same construct using the kernel language and assuming there is an AssignLabel procedure in Oz: local T in {AssignLabel T tree} T.right = {Func1 B} T.left = {Func1 A} end 1.Are the above constructs always equivalent? Note that they may suspend or abort at a different places in which case they are not considered to be equivalent. 2.How will your answer change if you are told that neither A nor B is unbound? 3.How will your answer change if you are told that neither A nor B is unbound, and Func1 never throws an exception? 4.How will your answer change if you are told that neither A nor B is unbound, and Func1 is a lambda combinator? 5.How will your answer change if you are told that neither A nor B is unbound, and Func1 never throws an exception, and Func1 is a lambda combinator?

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy37 Exercise The C++ language has a facility to declare static variables in a function. Read about them if you don’t know what they are. Now, conceptually describe – How can you add a similar facility to Oz? Will you add it as an extension of the kernel language or as a linguistic abstraction? (You need not follow the same syntax as C++. Your semantics should be approximately the same) Any realistic computer system has a memory cache for fast access to frequently used data. Read about caches if you don’t know what they are. Can you think of any issues with garbage collection in a system that has a memory cache?

C. Varela; Adapted w/permission from S. Haridi and P. Van Roy38 Exercise Do problems 3, 9 and 12 in Section 2.9 Read Sections 3.7 and 6.4