Subprograms

1. Subprograms subroutines, procedures, functions, methods

2. Why subprograms? • top-down structure - chunking • attach a name to a composite of instructions • reusable code • branch away and branch back main call sub call sub sub

3. Vocabulary parameter profile header / prototype float average(float list[], int n) { … } protocol formal parameters actual (arguments) av = average(marks,20); call

4. Functions vs Procedures • procedures are statements - do not return a value Collections.sort(marks, 20); • functions are expressions - return a value double x = 1000.0 + Math.exp(10.0); • in c, c++, Java, all methods are functions; can be used as procedures; ‘void’s must be used as procedures

5. Parameters • pass-by- • value • reference • name in mode (call) inout (call-return) out (return) keyword positional • example Java: • all parameters are positional • primitive parameters are in, pass by value • object parameters are inout, pass by reference

6. Keyword parameter passing • order of actual parameters can be changed if each parameter is identified by keyword (FORTRAN, Ada) • natural match with default parameters av = average(n=>20,list=>marks) av = average(list=>marks, n=>20)

7. Extended parameter models • variable numbers of parameters java varargs: last parameter can be array or sequence of arguments: public int sum(int… args) call: int[] x = {2,3,4,5,6,7}; int xsum = sum(x); int csum = sum(2,3,4,5,6,7);

8. Modes: Direction of data passing in - data goes into subprogram only at beginning of execution out - data goes from subprogram back to caller at end of execution inout - data passes in both directions: into subroutine at call and back to caller at end of execution

9. Direction of data passing in - protects caller’s data from effects of subprogram out - useful for initializing data in caller; alternative route for returning data inout - gives subprogram access to change caller data subprogram caller subprogram caller subprogram caller

10. Implementing parameters (1) • Pass-by-value • pass-by-value (in) • pass-by-result (out) • pass-by-value-result (inout) • Data is copied between actual and formal parameters a = 10 proc sub(int x) sub (a) { print a print x x = 1000 print x } x a

11. Implementing parameters (1) • Pass-by-value • pass-by-value (in) • pass-by-result (out) • pass-by-value-result (inout) • What happens when actual parameters are not variables? (constants or expressions)

12. Implementing parameters (1) • Pass by value,result, value-result a = 10 proc sub(int x) sub (a) { print a print x x = 1000 print x } sub stack x a

13. Implementing parameters (2) • Pass-by-reference (inout OR in if actual parameters are made read-only) • Formal parameter refers to same memory cell as actual parameter a = 10 proc sub(int x) sub (a) { print a print x x = 1000 print x } x a

14. Implementing parameters (2) • Pass-by-reference a = 10 proc sub(int x) sub (a) { print a print x x = 1000 print x } sub stack address of a a x

15. Implementing parameters (2) • Pass-by-reference • Formal parameter refers to same memory cell as actual parameter • What happens when actual parameters are not variables? (constants or expressions) java example jButton.addActionListener(new ButtonListener());

16. Implementing parameters (3) • Pass-by-name • formal is bound to actual only when accessed or assigned (i.e., not at call) • effect depends on form of actual parameter: • constant - same as pass-by-value • variable - same as pass-by-reference • expression - like reference but reference may change

17. Implementing parameters (3) - pass-by-name example procedure BIGSUB integer GLOBAL, LIST[1:2]; procedure SUB(PARAM) begin PARAM := 3; GLOBAL := GLOBAL + 1; // note scope! PARAM := 5; end; begin LIST[1] := 2; LIST[2] := 2; GLOBAL := 1; SUB(LIST[GLOBAL]); end;

18. Implementing Parameters (3) • Pass-by-name thunk list[j] sub(x) j=2 sub(list[j]) x j=4 x j list

19. Parameters - design issues (1) • type checking • no checking - mismatched types -> reinterpretation of data • type checking - control of type match or legal coercion

20. Parameters - design issues (2) • array parameters - for 2 or more dimensions, length of 2nd, 3rd, etc dimensions is needed to computer offset • tradeoff • compile-time (efficient) offset expression forces fixed array dimensions • call-time (less efficient) offset expression handles arrays of any size (java)

21. Parameters - design issues (3) security / efficiency tradeoff • security: design according to minimum access requirements: • in , out, inout • efficiency: reference is time and space efficient for large data objects but implies inout • compromises • allow programmer choice • ‘read-only’ references (C++) • what does java offer?

22. Passing procedures as parameters • example of procedure passing procedure m() var integer[3] arr = {1,2,3}; procedure s (integer[3] k) begin print (k[1]+k[2]+k[3]); end procedure sub (integer[3] cc, procedure w) begin w(cc); end begin sub(arr, s); end

23. Issues unique to procedure parameters (1) • Does protocol of actual parameter procedure match protocol of formal? • early Pascal unchecked • later Pascal – parameters in formal procedure parameter • c pointers to procedures are passed; their type identifies protocol

24. Issues unique to procedure parameters (2) scoping of variables • from definition of actual parameter • environment of call • environment of execution procedure m() var integer[3] arr = {1,2,3}; procedure s (integer[3] k) begin print (k[1]+k[2]+k[3]); end procedure sub (integer[3] cc, procedure w) begin w(cc); end begin sub(arr, s); end

25. Procedure parameters:procedures as data • LISP: functions are a data type • can be manipulated as data (define (area r)(times pi r r)) and • executed (interpreted) (eval(define (area r)(times pi r r))) (eval (area 10))

26. Function design (COSC 3036) • extreme definition: NO SIDE-EFFECTS • no access to global variables • only call parameters • only effect through return value • return values: • single primitive value – math model • single value including reference/pointer • any one value including record, array or procedure

27. Coroutines – preview to concurrency • subroutines in symmetric control model (not caller-callee relationship) • goal: virtual parallelism • Simula – process simulation • java – threads • classic example – large file copy • read and write coroutines with shared buffer

28. Sharing data space • global identifiers by scoping rules • instructions to compiler to share space (Fortran COMMON) • explicit specification of external units needed (Fortran 90, java)

29. Reusability with subprograms • OVERLOADING: reusing a subprogram name • in different scopes • with different protocols (like operators*) • conflict with default parameters • POLYMORPHIC: • different parameter types in different activations • dynamic typing • type templates C++ *C++ allows overloading of operators

30. generic parameter typesC++ templates template <class Etype> void Swap (Etype & First, Etype & Second) { Etype Temp = First; First = Second; Second = Temp; } ... in calling program int X = 5, Y = 6, Z = 7; double A = 3.5, B = 9.4; Swap(X,Y); //instantiate int version Swap(X,Z); //re-use int version Swap(A,B); //instantiate double version Swap(A,Z); // illegal – type mismatch

31. Reusability and compilation • problem: variables and procedures defined in one unit and accessed in another – type checking • separate compilation (Ada) • compile time check of compatibility • independent compilation (c) • no type checking – run time type errors • no compilation except complete programs (original Fortran II)

32. Separate Compilation • compilation checks library of exported entities for types and protocols of external references library A’s compilation unit int max(int,int) ? compile A unit A unit B function int max(int,int) i = max(j,k) compile B