Subprograms & their implementation Subprograms

A subprogram is a piece of code which can be called

•  Subprograms
by name (a process abstraction).
•  Parameter passing
•  Activation records •  Single entry point, control returned to caller
•  The run-time stack •  Several (nested) subprograms may be active, but only
•  Implementation of static and dynamic scope rules one executing
•  procedures = a command abstraction, called for an effect
•  functions = expression abstractions, returns a value
•  A header defines name, formal parameters, type of result
(signature, interface)

November
30,
2009
 Lennart
Edblom,
Inst.
f.
 1
 November
30,
2009
 Lennart
Edblom,
Inst.
f.
 2


datavetenskap
 datavetenskap


Parameters Design questions for subprograms

•  Parameter passing method(s)?
•  Parameterization of subprograms is accomplished by the •  Type checks formal <=> actual parameters?
interplay between formal and actual parameters •  Default values for parameters?
•  Formal parameters are local variables used to transfer •  Is nesting of subprograms allowed?
data between the subprogram and its environment •  Can subprograms be passed as parameters? Which
•  Actual parameters are the expressions / values bound to reference environment will be used?
formal parameters when the subprogram is called •  Overloaded subprograms?
•  Binding between a.p and f.p; usually position, sometimes •  Generic (polymorphic) subprograms?
name Functions:
•  Side effects allowed?
•  Allowed types for return values?

November
30,
2009
 Lennart
Edblom,
Inst.
f.
 3
 November
30,
2009
 Lennart
Edblom,
Inst.
f.
 4


datavetenskap
 datavetenskap


Parameter passing models Example program

A parameter passing model describes the mode •  program main

of communication between actual parameters var x;

and formal parameters. procedure P(a,b);

begin a:=a+b;

•  The direction of the data transmission can vary b:=b+x;

 in-mode formal parameter receives data from actual write(a,b,x)

 out-mode actual parameter receives data from formal end;

 in-out-mode both begin

•  The main methods of data transfer are x:=5;

 Transmission of a value data is copied P(x,x);

 An access path is transmitted a reference is copied write(x)

end

November
30,
2009
 Lennart
Edblom,
Inst.
f.
 5
 November
30,
2009
 Lennart
Edblom,
Inst.
f.
 6


datavetenskap
 datavetenskap


1
 Parameter passing methods Parameter passing methods (cont.)
•  Pass-by-value •  Pass-by-value-result
 The value of a.p. is used to initialize the corresponding f.p.  combination of both previous methods (⇒ in-out-mode)
(⇒ in-mode) •  Pass-by-reference
 Normally implemented by copying the value  The formal parameter becomes an alias for the a.p, which
•  Pass-by-result must be a variable (⇒ in-out-mode)
 a.p. (which must be a variable) is updated with the value  problems
of f.p. (⇒ out-mode) »  aliases decreases readability and reliability. The effect
 Normally implemented by copying of a subprogram cannot be understood without studying
 Problems: the context of the call.
»  Parameter collision e.g. sub(x,x) »  Two types of aliases: per definition (if the parameter is a
»  When is the address of the a.p. computed? (e.g. in non-local variable) and by parameter collision
sub(a[i]) if i is changed in sub)?
»  What happens if a.p is an expression?
November
30,
2009
 Lennart
Edblom,
Inst.
f.
 7
 November
30,
2009
 Lennart
Edblom,
Inst.
f.
 8

datavetenskap
 datavetenskap


Parameter passing methods (cont.) Other questions

•  Pass-by-name •  Function results - similar to a parameter in out-mode
 The a.p is textually substituted for the f.p. •  Subprograms as parameters
(⇒ strange in-out-mode)  Central in functional languages, allowed in some other lang.
 problems: ineffective, hard to implement, confusing  Common (in statically scoped languages): The reference
(⇒ not appropriate for general programming environment is passed with the subprogram (deep binding)
languages) •  Overloaded subprograms
 in the absence of side effects ≈ lazy evaluation, but  Several SP with same name in the same reference env.
then usually evaluated only once (call-by-need)  Distinguished by different ”signature”
 Often same effect as c-b-r, but not always (Ex: s[i] is a  Flexible, but may decrease readability
parameter, i is changed in the subprogram) •  Coroutines
 Symmetric relation between subprograms
 ”Quasi-concurrency”

November
30,
2009
 Lennart
Edblom,
Inst.
f.
 9
 November
30,
2009
 Lennart
Edblom,
Inst.
f.
 10


datavetenskap
 datavetenskap


Other questions (2)

•  Generic / polymorphic subprograms
 Can have param:s of different type on different activations
 Overloading = ”ad-hoc polymorphism”
 Parametric polymorphism = a type as parameter
 In OO-lang. still another variant (dynamic binding)
 Exists e.g in Ada, C++, (Java 5.0), ML Ex (ML):
  fun generic_sort precedes itemlist =

let fun sort nil = nil

| sort [x] = [x]

| sort (x::y::xs) = if precedes (x,y) then...

in

sort itemlist

end;
val ascending_int_sort = generic_sort ((op <):(int*int->bool))

November
30,
2009
 Lennart
Edblom,
Inst.
f.
 11


datavetenskap