Building Abstractions with Procedures (Part 2)

1. Building Abstractions with Procedures (Part 2) CS 21a: Introduction to Computing I First Semester, 2013-2014

2. Last Time… • Giving names to and abstracting away chunks of code that look similar, so that code becomes cleaner

3. Today… • Exploring combinations of procedures • More detailed discussion of procedural programming

4. Outline • Combinations through Procedures • The Method Stack versus the Tree of Stack Frames • Scope versus Environment

5. Procedures Can Use Procedures • Writing a procedure is like writing a new smaller program embedded in a larger one. • The larger algorithm delegates part of the problem, or a sub-problem to the procedure. • And this can go on recursively. • Sub-problems can have further sub-problems. • Procedures can use procedures.

6. Combination through Procedures staticintsquare(int x) { return x*x; } staticintsum_of_squares(int x, int y) { return square(x) + square(y);}

7. Procedure Definitions Can Have Procedure Calls • A procedure definition can serve to expand the “primitives” that a higher-level programmer (possibly yourself) can use.

8. Procedure Definitions Can Have Procedure Calls • The squareprocedure is a blackboxed “primitive” that the sum_of_squaresprogrammer may use… • without thinking about how squareworks… • In the same manner that the squareprogrammer uses the * operator… • without thinking about how *works, • And the sum_of_squaresprocedure can be used in another procedure defintion… • without thinking about how sum_of_squaresworks.

9. Remember This? • Civilization advances by extending the number of operations that we can perform without thinking about them. • Alfred North Whitehead (1861-1947)

10. Practice Programming Problem: Square Hypotenuse • Include the procedure definitions above into your program and print out the square of the hypotenuse of a given triangle. Don’t forget to test your program. • Assume the following declarations: int a = 5; int b = 3;

11. Outline • Combinations through Procedures • The Method Stack versus the Tree of Stack Frames • Scope versus Environment

12. Practice • Try to imagine how the method stack evolves in an execution of a program that calls sum_of_squares.

13. Practice main

14. Practice sum_of_squares main

15. Practice square sum_of_squares main

16. Practice sum_of_squares main

17. Practice square sum_of_squares main

18. Practice sum_of_squares main

19. Practice main

20. Tree of Stack Frames • A computation has a method stack. • But an algorithm has a tree of stack frames. • Like how expressions have expression trees • A computation lives out an algorithm by walking down this tree and backtracking when it reaches a dead end.

21. Practice Programming Problem: Interest Once More • If you haven’t done so already, rewrite the program you wrote for Bob so that the tree of stack frames of the algorithm is more than two levels deep.

22. Procedure Calls Can Be Nested • Like expressions print(square(4)); print(sum_of_square(2, 3) + square(square(5))); print(square(square(3)));

23. Procedure Calls Can Be Nested • But if you find yourself nesting too much, maybe you need intermediate variables. intinput = 3; inthypercube = square(square(input)); intanswer = sum_of_squares(hypercube, hypercube); print(answer);

24. Or New Procedure Definitions staticinthypercube(int x) { return square(square(x)); } … public static void main(String args[]) { intinput = 3; inttemp = hypercube(input); intanswer = sum_of_squares(temp, temp); print(answer); }

25. Practice • For each slide above, starting from 3 slides ago… • Draw the tree of stack frames of the algorithm. • Draw the evolution of the method stack of a computation, include environments. • You may think of + as a procedure with two parameters, and include that too.

26. Outline • Combinations through Procedures • The Method Stack versus the Tree of Stack Frames • Scope versus Environment

27. Parameter Names of Different Procedure Definitions Are in Different Scopes • Note how the x of the square definition is not the same as the x of the sum_of_squares definition. • Remember composition of functions in algebra? • Each procedure definition has its own scope or namespace. • The block structure is Java’s way of enforcing scope. • Each pair of curly braces creates a new scope.

28. Parameter Names of Different Procedure Definitions Are in Different Scopes staticintsquare(int x) { return x * x; } staticintsum_of_squares(int x, int y) { return square(x) + square(y);} These refer to different abstract entities, to different variables. block structure

29. Scope Versus Environment Scope Environment (Running) procedure calls have environment. Each (running) call to square within sum_of_squares is independent of each other. The parameter x of square can possibly take on different values with each (running) call. • Procedure definitions have scope. • The x in square is different from the x in sum_of_squares. • The x in the (written) call square(x) in sum_of_squares is different from the x in square.

30. Scope Versus Environment Scope Environment Different environments: The set of arguments have different values different with each (running) procedure call. Each (written) procedure call in any given procedure definition will yield a new (running) procedure call with a new environment. • Same scope: The identifiers of the parameters of a procedure definition always refer to the same variables (parameters), even if they may have different values at different calls.

31. Scope Versus Environment Scope Environment Different environments: Obviously, (written) calls for different procedure definitions will produce different environments at run-time. • Different scope: The identifiers of the parameters of different procedure definitions refer to different variables, even if they look the same symbolically.

32. Two Kinds of Contexts • Scopes are contexts for names. • Scopes exist in programs (the written algorithm). • Environments are contexts for variables. • Environments exist in computations (the running program). • Algorithms have neither scope nor environment. • Variables have no names until algorithms are written. • Variables have no values until programs are run.

33. Recall! • The name/identifier is not the variable! • The name/identifier is a symbol. • The variable is the abstract entity which the symbol refers to in a program. • The value is not the variable! • The value is data. • The value is the concrete entity which the variable takes on in a computation.

34. AGAIN • Different environment means different values for the same variables. • Different scope means different variables for the same identifiers.

35. An Analogy to Clear That Up • Imagine you are both a rock star and a computer science student.

36. An Analogy to Clear That Up • One day, while rehearsing with your band, you have the following conversation: • You: “Yo Alice, could you play me those notes again.” • Alice: “What notes?” • You: “The opening to our new song.” • Alice plays the notesA, C, D, E because she’s memorized it.

37. An Analogy to Clear That Up • You: “Try to play these notes instead: A, B, D#, E.” • Alice executes the same procedure, play, but this time with different environment, a different part of her memory, and returns a different tune. • You: “Then play these notesI’ve written here.” • Pass by value: While Alice is actually playing, she doesn’t have to care where the actual notes came from, she can always think of them only as “the notes.”

38. An Analogy to Clear That Up • After rehearsing, you realize you have a CS exam and rush to your friend to borrow notes: • You: “Hey Bob, could you lend me your notes?” • Bob: “What notes?” • You: “I’m especially confused about scopes and environments.” • Bob lends you his notes, but they’re probably not something you’re going to sing with anytime soon.

39. An Analogy to Clear That Up • Alice asks Bob to lend her his notes from music class (because Bob is awesome and also majors in music), so that she can playnotes better. • There should be no confusion here.

40. An Analogy to Clear That Up • Theseare (written) procedure calls. • These are parameter identifiers. • These are identifiers for variables which are not parameters.

41. An Analogy to Clear That Up • Theserepresent abstraction barriers. • These represent parameters. • These represent variables which are not parameters.

42. An Analogy to Clear That Up • The abstract entities referred to by these become (running) procedure calls. • The abstract entities referred to by these take on arguments, which may be directly supplied by these or indirectly supplied by these. • The abstract entities referred to by these take on values, which may be directly supplied by these or indirectly supplied by these.

43. By the Way • For every block, there is also a scope for procedures. • Does not coincide with the scope for variables

44. Recitation • Given that you understand the differences between (identifiers, programs, scope); (variables, algorithms); and (values, computations, environment), answer the following question and state the reasoning behind your answers.

45. Will This Work? If Yes, What Does bar(5) Return? staticintfoo(intx) { return x*x; } staticintbar(inty) { returnfoo(x); }

46. Will This Work? If Yes, What Does bar(5)Return? staticintfoo(intx) { return x*x; } staticintbar(int x) { returnfoo(x); }

47. Will This Work? If Yes, What Does bar(5)Return? staticintfoo(intx) { return x*x; } staticintbar(int a) { returnfoo(a); }

48. Will This Work? If Yes, What Does bar(5)Return? staticintfoo(intx) { return x*x; } staticintbar(int a) { returnfood(a); }

49. Will This Work? If Yes, What Does bar(5)Return? staticintfoo(intx) { return x*x; } staticintbar(int a) { returnfoo(a, b); }

50. Will This Work? If Yes, What Does bar(5)Return? staticintfoo(intx) { return x*x; } staticintbar(int a) { returnfoo(a, a); }