Subprograms

Subroutines 17/05/2017 Procedures Functions Methods

An introduction DFR -- PL Subprograms

1 What is a subprogram?

• A “code package” with a name, … • … and possibly parameters … • … and a type (functions) 17/05/2017

Inspired by the idea of a mathematical function BUT mathematical functions have only IN PARAMETERS

SUBPROGRAMS may have IN, OUT & IN‐OUT parameters (ADA) DFR -- PL Subprograms

Code abstractions – reusable, lead to more abstract design  Modules and interfaces 2 Terminology & Ideas

• Between different programming languages, the terminology is mixed • E.g. Lisp calls these “procedures” BUT they return a value • E.g. OO calls these “methods” 17/05/2017 • E.g. calls them functions but allows a  procedure • Subprograms introduce the concept of since they define a new “environment” • The scope of a name is the environment or environments in which the name is visible

or accessible DFR -- PL Subprograms • This in turn leads to “name hiding” –when a name in a hides another object with the same name in an outer environment 3 •  local and non‐local environments Parameters

• Subprograms may have parameters

• FORMAL PARAMETER IDENTIFIER 17/05/2017

• ACTUAL PARAMETER EXPRESSION

• Examples 2 literal value 2+2 literal expression DFR -- PL Subprograms The actual parameters aidentifier are the ARGUMENTS to the subprogram f(x) function call a + f(x) * 2 expression 4 Parameters

Parameter passing semantics also use mixed terminology!

Call-by IN OUT IN-OUT Pass-by 17/05/2017 Value

Reference

Return DFR -- PL Subprograms

Value‐ 5 return Side effects

• A SIDE EFFECT is when a data object outside the scope of the subroutine is changed (either by choice or accident) • Mathematical functions do not have side effects (pure)

• Often programming do allow side effects 17/05/2017 • More efficient than copying large structures or arrays • Input / Output is a side effect • The parser ‐ reader() has no parameters but has a result • Program text  buffer

• Opening a file for read / write DFR -- PL Subprograms

• The use of side effects should be “by choice” 6 Side effects & Parameters

• OUT and IN‐OUT parameters have side effects • Call‐by reference and call‐by value‐return have side effects • HOWEVER • The point in time at which these side effects happen should also 17/05/2017 be considered • During the execution of the subroutine reference • On exit from the subroutine return

• Call‐by value is the “cleanest” parameter passing method DFR -- PL Subprograms • No side effects • Conscious use of side effects is required i.e. by choice 7 Subroutines revisited

• Functions may have 2 parts • The function declaration , interface # & type of parameters • The function implementation 17/05/2017 • Functions (methods) may be declaration • Private • Public

implementation • A module interface is often DFR -- PL Subprograms a collection of function e.g. the C .h files (public functions) 8 Procedures vs functions

• Procedures • Design issues • parameterised code sequence • parameter passing methods ? • access to data objects • type checking actual/formal ? • direct to non‐local • local variables static/dynamic?

• via parameters (in, out, in/out) • s/progs as parameters ‐ what is 17/05/2017 the referencing environment ? • Functions (user defined ops) • nesting of s/prog definitions ? • model ‐ math functions • s/prog overloading ? • fn: T1 x T2 x … x Tn => TF • generic s/progs ? • may appear in expressions • support for closures? • returns value • separate / independent

compilation available? DFR - - PL Flow of Control

9 Subroutines – in summary

• Subroutines have led to a “field of ideas” over time • The terminology may be “mixed” and perhaps confusing • A “code package” with a name…

• …and possibly a return type… 17/05/2017 • …and possibly parameters… • Which may be IN, OUT, IN‐OUT • And have different call‐by / pass‐by semantics • value, reference, return, value‐return

• Side effects which may take place during execution or on exit DFR -- PL Subprograms • Introduces the idea of scope and environments • local & non‐local environments • non‐local may have static / dynamic semantics 10 • Subroutines may have a declaration and an implementation part 17/05/2017

Subroutines & run‐time

An Introduction DFR -- PL Subprograms

11 Subprograms – call subprog(a, b, c);

• Process abstraction • Access to data objects • characteristics • direct to non‐local • single • via actual parameters • control is transferred • positional parameters 17/05/2017 • control returned at end • keyword parameters (name) • subprogram definition • Ada & Fortran 90 • heading (prototype) • may be mixed !!! • name & type • default parameter values • formal parameter list • C++, Ada, Fortran 90 • subprogram call / return • actual parameters must match the formals in both • transfer of control number & type (usually) DFR - - PL Flow of Control

12 Subprograms

• Subprogram call Code AR • parameter passing mechanism • allocation of local DOs

data 17/05/2017 (data objects) • execution status of calling (sub)program unit data • transfer of control to subprogram • execute the subprogram • Fortran 77 ‐ static DFR -- PL Subprograms • transfer of control from • Algol family –dynamic subprogram • return value(s) (if any) • Algol 1960 –the stack • (run‐time stack) 13 General Model: Activation Record

Static • Activation Record (AR) issues static DOs / code • static link: static scope • dynamic link: calling env

Stack • format fixed at compile time 17/05/2017 dynamic local DOs • size may vary at run time • standard implementation ‐ run time stack Unallocated • why? ‐ call and return memory semantics (path within tree) & Heap reuses space in the stack • DFR -- PL Subprograms user allocated recursion ‐ several AR instances • dynamic DOs DO = data object

14 Activation Records

• Fortran 77 (static) • Algol family (dynamic)

Function value Function value

Parameters Parameters 17/05/2017 Local DOs Local DOs Return address Static link Dynamic link • format known at compile time DFR -- PL Subprograms (DO = data object) Return address

15 17/05/2017

Subroutines & environments

An Introduction DFR -- PL Subprograms

16 Referencing Environments

• formal parameter semantic static modes: in, out, in‐out NLE stack • Parameter passing methods LE • pass by value (in) • pass by result (out) 17/05/2017 heap • pass by value‐result (in‐out) heap • pass by reference (in‐out) • (pass by is also called call by) SF caller (actual) callee (formal) SF a x b y SF DFR - - PL Flow of Control c z static = links = dynamic SF = stack frame 17 Activation Records: static & stack memory

prog xyz; p: real; • Activation Record Instances (ARI) static + stack memory proc A(x: int): y: bool; • run time stack proc C(q: bool); {(*3*) … }

{ … (*2*) C(y); … } (*A*) ARI C 17/05/2017 proc B(r: real); s,t: int; ARI A ARI A { … (*1*) ... A(s); … } (*B*) { … B(p); …} (*main*) ARI B ARI B ARI B ARI ARI ARI xyz  B  A  C xyz xyz xyz DFR -- PL Subprograms xyz data objects  static A, B, C data objects  stack (*1*) (*2*) (*3*) 18 Local & Non‐local References

Static  links  dynamic x, y, z A uses x, y, z A x B uses x, y, z B x, y C uses x, y, z 17/05/2017 C x symbol table x, y, z

x, z C uses x, z B uses x, z A B C x DFR -- PL Subprograms x A uses x, z z x, z

Dynamic: C(C.x,P.y,P.z), B(B.x,B.y,P.z), A(A.x,B.y,P.z) 19 Dynamic: A(P.x,A.z), B(B.z,A.z), C(C.x,A.z) P=program Local & non‐local references

• Static or Lexical refs A • Lexically (textual) B enclosing environment

C 17/05/2017 symbol table • Dynamic refs • The environment of the callee A B C • i.e. trace back the call

sequence DFR -- PL Subprograms

20 Modules and separate compilation 17/05/2017 DFR -- PL Subprograms Modules – export and import functions Functions are private or public Collection of modules (e.g. C parser / OO) The function prototype is exported i.e. an interface 21 Parameter passing 17/05/2017 semantics revisited DFR -- PL Subprograms

22 Parameter Passing Mechanisms

• Pass by value • Pass by value‐result • value of actual parameter is • combination of pass by value copied to formal parameter and by result (see above) • issues • Pass by reference

• expensive for large structures 17/05/2017 (e.g. arrays) • access path (reference i.e. • extra storage required address) to actual parameter • Pass by result is copied to formal parameter (aliasing !) • value of formal parameter is copied to actual (at end of • issues subprogram execution) • more efficient than • issues value/result • as pass by value • slower (indirect) access DFR - - PL Flow of Control

23 Parameter Passing Mechanisms

Some problems • By value • pass by result • On entry: fp = value(ap) • During : fp  ap ‐ no effect call fn(a, a) / formal fn(x,y) • On exit: fp  ap ‐ no effect • By result • whichever of x, y is last 17/05/2017 assigned decides the result • On entry: ‐‐‐ • During : fp  ap ‐ no effect • a= x; a = y || a = y; a = x ??? • On exit: ap = value(fp) • pass by reference • By value result • On entry: fp = value(ap) call fn(&a, &a) / formal fn(*x,*y) • During : fp  ap ‐ no effect • means x, y are aliases • On exit: ap = value(fp) • a= last assignment to *x || *y • By reference DFR - - PL Flow of Control no control over in / out semantics • On entry: fp = address(ap) • During : fp  ap ‐ can change • On exit: ‐‐‐

24 Subprograms: Summary

• Call semantics • Parameter passing • stack + ARIs • By value (in) • static links ‐ static scope • By result (out) (lexical scope) • By value‐result (in‐out) • dynamic links • By reference (in‐out) 17/05/2017 • call sequence • dynamic scope • Formal parameters are IDs • References to data objects • Actual parameters are • local (within the ARI) expressions • non‐local DFR -- PL Subprograms

25