Procedure swap(a, b : integer); var temp : integer; begin temp := a; a := b; b := temp end;Won't always work, e.g.
swap(i, a[i]) with i = 1, a = 3, a = 17.
No way to define a correct swap in Algol-60!
Expressive power - Jensen's device:
To compute x = Sum for i=1 to n of Vi
real procedure SUM (k, lower, upper, ak); value lower, upper; integer k, lower, upper; real ak; begin real s; s := 0; for k := lower step 1 until upper do s := s + ak; sum := s end;What is result of sum(i, 1, m, A[i])?
What about sum(i, 1, m, sum(j, 1, n, B[i,j]))?
If evaluating parameters has side-effects (e.g., read), then must know how and how many times parameter is evaluated to predict what will happen.
Therefore try to avoid call-by-name with expressions with side-effects.
Lazy evaluation is efficient implementation of call-by-name where only evaluate parameter once. Requires that there be no side-effects, since owise get diff. results.
Implement call-by-name using thunks - procedures which evaluate expressions - difficult and slow. Must pass around code for evaluating expression (including environment defined in). Can use the same THUNK's as show up in environment based interpreter.
Note different from call-by-text (which would allow capture of free vbles).
Can classify parameter passing by copying (value, result, or value-result) or definitional.
Definitional have constant, variable, procedural, and functional.
Constant parameters are treated as values, not variables - different from
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.
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.When b(a()) is called, a() returns a function which depends on the non-local variable m, but m has gone away by the time the function is actually applied. Hence languages (like ML) which allow functions to return functions cannot use the simple stack discipline - must keep around activation records even after their associated function or procedure has returned.
Often happens with global vbles
Also call by reference parameters, very dangerous in call-by-name.
Very disturbing in functions since can make it hard to figure out values of expressions. Example:
A[f(j)] := j * f(j) + jMakes it harder to optimize - e.g. evaluate f(j) only once.
Most common ways of arising: global and parameter, two parameters, pointers
Procedure swap( var x, y: integer); begin x := x + y; y := x - y; x := x - y end;
Tricky way of completing swap of x and y w/out extra space.
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.
Causes problems with correctness since any two vbles may refer to the same object.
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.
(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.
i.e. treated as implicit parameters
E.g., constant, variable (def. & declaration), procedure & function, type(?)
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.
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.
Ex: pop(push(S,x)) = S,
if not empty(S) then push(pop(S), top(S)) = S
Data + Operations (+ possibly equations) = Algebra
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.
Usually not accessible to user.
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
How to represent ADT's in programming languages?
Three predominant concerns in language design:
Reusable modules to represent ADT's quite important.
Examine implementation in Simula 67, Ada, Modula 2, Clu, and ML..
Derived from Algol 60. Simulation language.
Provided notion of class.
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 *) endRefer to objects through references:
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 ...Notice that attributes are available to all users.
Representation not hidden.
Come back to discuss subclasses later when discussing object-oriented languages.
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.Key is representation is hidden.
Packages used to define abstract data types.
Package together type, operations (& state) and hide rep.
Provides support for parameterized packages (polymorphism)
package <package-name> is -- declarations of visible types, variables, constants, and subprograms private -- complete definitions of private types and constants end <package-name>; package body <package-name> is -- definitions of local variables, types, and subprograms, and complete bodies for -- subprograms declared in the specification part above. Code for initialization -- and exception handlers end <package-name>;Sample Program:
package VECT_PACKAGE is -- declarations only type REAL_VECT is array (INTEGER range <>) of float; function SUM(V: in REAL_VECT) return FLOAT; procedure VECT_PRODUCT(V1,V2 : in REAL_VECT) return FLOAT; function MAX(V: in REAL_VECT) return FLOAT; end VECT_PACKAGE ; package body VECT_PACKAGE is -- details of implementation function SUM(V: in REAL_VECT) return FLOAT is TEMP : FLOAT := 0.0; begin for I in V'FIRST..V'LAST loop TEMP:= TEMP + V(I); end loop; return TEMP; end; -- definitions of VECT_PRODUCT and MAX subprograms would appear here end VECT_PACKAGE ; with VECT_PACKAGE, TEXT_IO; -- used to make separately compiled package visible procedure MAIN is use VECT_PACKAGE, TEXT_IO; -- eliminates need for qualifiers package INT_IO is new INTEGER_IO(INTEGER); --instantiation of generic packages package REAL_IO is new FLOAT_IO(FLOAT); use INT_IO, REAL_IO; K: INTEGER range 0..99; begin loop GET(K); exit when K<1; declare -- start of block A : REAL_VECT(1..K); -- provides subscript bounds begin for J in 1..K loop GET(A(J)); PUT(A(J)); end loop; PUT("SUM = "); PUT(SUM(A)); -- uses package function end; -- of block end loop; end MAIN ;SOPHISTICATED (generic) STACK EXAMPLE
Stack represented internally in package (closer to object-oriented than get w/ Modula 2)
generic length : Natural := 100; -- generic parameters type element is private; -- only assignment and tests for = may be done on objects of "private" type -- "limited private" is also available. package stack is procedure push (X : in element); procedure pop (X: out element); function empty return boolean; stack_error : exception; end stack; package body stack is space : array (1..length) of element; top : integer range 0..length := 0; procedure push (X : in element) is begin if full() then raise stack_error; else top := top + 1; space(top) := X; end if; end push; procedure pop (X: out element) is begin if empty() then raise stack_error; else X := space(top); top := top - 1; end if; end pop; function empty return boolean is begin return (top = 0); end; function full return boolean is begin return (top = length); end; end stack;
Notice: Data structure of stack is entirely hidden from user -
there is no object of type stack available to user.
How to use:
package stack1 is new stack(20,integer); package stack2 is new stack(100, character); -- Note that this initializes length in both cases to 0 use stack2; stack1.push(5) if not stack1.empty() then stack1.pop(Z); endif; push('z');Note: Package definition is very much like that of a record with procedures allowed as (non-updateable) fields. E.g.
stack = package push : procedure (X : in element); pop : procedure (X: out element); empty : function return boolean; stack_error : exception; end package;
One of two key ideas behind object-oriented programming.