CS 334 Programming Languages Spring 2000 Lecture 13

Procedures and functions as parameters and return values

When pass function (or procedure) parameters in stack-based languages, must also pass the equivalent of a closure. In particular must pass the environment in which the function was defined. This is accomplished by passing the appropriate static pointer with the function so that can find non-local variables. Usually pass the pair (ep,ip) of environment pointer and instruction pointer as the "closure" of a procedure, when it is passed as a parameter.

Returning functions from functions is harder since defining environment may go away:

program ret;

function a(): function (integer): integer;
        var m: integer;
        
        function addm (n: integer): integer;
                begin
                        return (n + m)
                end;

        begin (* a *)
                m := 5;
                return addm
        end; (* a *)

procedure b (g: function(integer): integer);
        begin (* b *)
                writeln(g(2))
        end (* b *)

begin (* main *)
        b(a())          (* note that a() returns a function, which is                                   
                       then passed to b *)
end.

Correspondence Principle

Definitional have constant, variable, procedural, and functional.

Constant parameters are treated as values, not variables - different from call-by-value.
Default for Ada in parameters.

Can think of call-by-name as definitional with expression parameter.

Note that difference in parameter passing depends on what is bound (value or address) and when it is bound.

Another way of classifying parameters is to note that each parameter mechanism corresponds to declaration in language:

• constant parameter: constant def - value bound to identifier.

• variable parameter: variable renaming definition - new name given to old variable

• value parameter: new variable declaration w/ initialization

• procedure parameter: procedure declaration

E.g., constant, variable (def. & declaration), procedure & function, type(?)

What about call-by-name?

Two major problems which arise with subprograms:

• side-effects

• aliasing

Side-effects:

Very disturbing in functions since can make it hard to figure out values of expressions. Example:

        A[f(j)] := j * f(j) + j 

Aliasing:

Example:

        Procedure swap( var x, y: integer);
        begin   
            x := x + y;
            y := x - y;
            x := x - y
        end;

This is a tricky way of completing a swap of x and y w/out extra space.

Unfortunately, it doesn't always work - swap (a,a) (but does work with value-result! )

Can get similar probs with A, A[i] as parameters and pointers

Another problem: Overlap btn global vble and by-reference parameter.

Aliasing causes problems with correctness since any two vbles may refer to the same object. It also makes it difficult to optimize if can't predict when a vble might be changed.

If no aliasing, can't detect difference btn call-by-reference and call-by-value-result. But not semantically equivalent if aliasing is possible.

Leads to problems in Ada where language definition does not specify whether in-out parameters are to be implemented by reference or value-result. (Illegal program if it makes a difference - but not detectable!)

Unfortunately Ada doesn't enforce no aliasing. Therefore possible problems with in out parameters.

Euclid (variant of Pascal) designed to write verifiable programs. Attempted to eliminate aliasing. Unfortunately some can only be caught at run-time, e.g. p(A[i], A[j]). Legality assertions generated to check run-time problems. Global vbles had to be explicitly imported to avoid problems. I.e. treated as implicit parameters

Problems with writing large programs:

1. Side effects - hidden access

2. Indiscriminant access - can't prevent access - may be difficult to make changes later

3. Screening - may lose access via new declaration of vble

4. Aliasing - control shared access to prevent more than one name for reference variables.

Characteristics of solution:

1. No implicit inheritance of variables

2. Right to access by mutual consent

3. Access to structure not imply access to substructure

4. Provide different types of access (e.g. read-only)

5. Decouple declaration, name access, and allocation of space. (e.g. scope indep of where declared, similarly w/allocation of space - like Pascal new)

Abstract Data Types

Package data structure and its operations in same module - Encapsulation

Data type consists of set of objects plus set of operations on the objects of the type (constructors, inspectors, destructors).

Want mechanism to build new data types (extensible types). Should be treated same way as built-in types. Representation should be hidden from users (abstract). Users only have access via operations provided by the ADT.

Distinguish between specification and implementation.

Specification:

Method for defining data type and the operations on that type (all in same place). The definitions should not depend on any implementation details. The definitions of the operations should include a specification of their semantics.

Provides user-interface with ADT.

Typically includes

1. Data structures: constants, types, & variables accessible to user (although details may be hidden)

2. Declarations of functions and procedures accessible to user (bodies not provided here).

Ex:

        pop(push(S,x)) = S, 

        if not empty(S) then push(pop(S), top(S)) = S

Implementation (Representation):

Method for collecting the implementation details of the type and its operations (in one place), and of restricting access to these details by programs that use the data type. Provides details on all data structures (including some hidden to users) and bodies of all operations.

Note that ADT methodology is orthogonal to top-down design

• Partition first into modules corresponding to ADT's.

• Use top-down within ADT's and in larger programs using ADT's

Three predominant concerns in language design:

• Simplicity of design

• Application of formal techniques to specification & verification

• Keep down lifetime costs

• Separate (but not independent) compilation.

• Want to maintain type checking

• Control over export and import of names (scope)

Simula 67

Derived from Algol 60. Simulation language.

Provided notion of class.

• Each kind of object being simulated belongs to a class.
• Objects called class instances.
• Class similar to type but includes procedures, functions, and variables.

class vehicle(weight,maxload);
    real weight, maxload;
begin
    integer licenseno;      (* attributes of class instance *)
    real load;
    Boolean procedure tooheavy;
        tooheavy := weight + load > maxload;
    load := 0;      (* initialization code *)
end

    ref(vehicle) rv, pickup;
    rv1:- new vehicle(2000,2500);
    pickup:- rv1;       (* special assignment via sharing *)
    pickup.licenseno := 3747;
    pickup.load := pickup.load +150;
    if pickup.tooheavy then ...

Representation not hidden.

Come back to discuss subclasses later when discussing object-oriented languages.

Intermezzo: What are problems with defining a new type in terms of an old?

1. Representation might have several values that do not correspond to any values of the desired type (e.g., (3,0)).

2. Representation might have multiple values corresponding to the same abstract value (e.g., (1,2), (2,4), etc.)

3. Values of the new type can be confused with values of the representation type.

Abstract data type is one that is defined by group of operations (including constants) and (possibly) a set of equations. Set of values only defined indirectly as those values which can be generated by ops, starting from constructors or constants.

E.g., Stack defined by EmptyStack, push, pop, top, and empty operations and equations.

   pop(push(fst,rest)) = rest, 
   top(push(fst,rest)) = fst, 
   empty(EmptyStack) = true, 
   empty(push(fst,rest)) = false, 
   etc.