IEEE TRANSACTIONS ON SOFTWARE, ENGINEERING, VOL. SE-9, NO. 1, JANUARY 1983 Simulation of Procedure Variables Using Ada Tasks DAVID A. LAMB AND PAUL N. HILFINGER Abstract-We give a technique for partially simulating procedure vari- ables using Ada tasks. The simulation involves using interface tasks, a technique which may be useful for other problems. Index Terms-Ada, procedure variables, programming languages, pro- gramming techniques, tasking. I. INTRODUCTION A procedure variable is a programming language object that can be called like a procedure, but which can be associated with different code bodies at different points in the execution of the program. The Ada language [11 does not include procedure variables. This paper describes a technique for simulating procedure variables in Ada, using the language's tasking facilities. We approached this problem as an interest- ing exercise, having been motivated by the following observa- tion: Ada has task variables, which have entries, which resemble procedures. Does this give us a way of implementing proce- dure variables? In the following, we refer to both entry calls and procedure calls. We will always say "entry call" or "makes an entry call" when referring to the former. The unmodified word "call" always means "procedure call" or "makes a procedure call." Consider a procedure of the form procedure P(X: in Ti; Y: out T2; Z: in out T3) is procedure body end; The signature of such a procedure is the sequence of modes (in, out, and in out) and types (Tl, T2, and T3) of the param- eters. In a language with procedure variables or procedure parameters, the declaration, assignment, and call of a proce- dure variable might look something like this: VI: procedure (X: in TI; Y: out T2; Z: in out T3); procedure Cl (X: in Tl; Y: out T2;Z: in out T3) is body ofprocedure constant end; VI :=Cl; VI (PI, P2, P3); Manuscript received September 10, 1980; revised January 14, 1981. This work was supported by the Defense Advanced Research Projects Agency (DOD), ARPA Order 3597, monitored by the Air Force Avion- ics Laboratory Under Contract F33615-78-C-1551. D. A. Lamb is with the Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213. P. N. Hilfinger was with the Department of Computer Science, Car- negie-Mellon University, Pittsburgh, PA 15213. He is now with the Department of Electrical Engineering and Computer Science, Univer- sity of California, Berkeley, CA 94720. We will show a set of Ada definitions that result in the frag- ment shown in Fig. 1. The relationships we set up are illus- trated in Fig. 2. Each procedure constant is represented by a procedure con- stant task and a corresponding interface task. The procedure constant task makes an entry call on its interface task to ob- tain parameters and return results. A procedure variable con- tains a pointer to an interface task. To simulate a procedure call on the current procedure associated with a procedure variable, a user program calls an entry of the interface task pointed to by that procedure variable. Assignment of pro- cedure variables is simply assignment of pointers to interface tasks. The interface tasks are required so that the procedure con- stant task and the tasks that use it can remain anonymous to each other. A user of procedure variables cannot uniformly reference two different tasks unless the two tasks can be reached through objects that have same type, because of the strong typing rules of the language. The interface, in turn, cannot be written to directly reference objects of an arbitrary set of distinct task types. We must therefore write it in such a way that it never needs to make entry calls, but instead accepts entry calls from user programs and from procedure constant tasks. This way of organizing the tasks works be- cause the tasking constructs let the caller of a task be anony- mous to the called task. II. THE TRANSFORMATION The first step is to introduce the interface task type, whose structure depends solely on the signature of the procedure. There will be one such type for each different signature. task type IP is entry Call(X1: in TI; YI: out T2; Z1: in out T3); entry Start-Call(X2: out TI; Z2: out T3); entry End-Call(Y2: in T2;Z2: in T3); end; type ProcedureType is access IP; The three entries of this task type have signatures derived from that of the procedure variable. The signature of the Call entry is identical to that of the procedure variable; this entry is called by user programs at points where they wish to call the procedure variable. The signatures of the Start-Call and End-Call entries have the modes "inverted"; in parameters become out parameters, and vice versa. These entries are called from the procedure constant to pick up and return parameters. Next, we transform all procedure variables and procedure parameters into parameters of type ProcedureType. Calls 0098-5589/83/0100-0013$01.00 © 1983 IEEE 1 3