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. C calls them functions but allows a void type procedure • Subprograms introduce the concept of scope 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 subroutine 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 subroutines 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 prototype, interface # & type of parameters • The function implementation return type 17/05/2017 • Functions (methods) may be declaration • Private • Public implementation • A module interface is often DFR -- PL Subprograms a collection of function prototypes 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 entry point • 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.