XEROX
BUSINESS SYSTEMS
System Development Department
August 12, 1978

To:Mesa Language Working Group

From:Dick Sweet

Subject:Mesa Language Working Group minutes

File:[iris]<sweet>lwg>lwg9aug78.bravo

The Language Working Group met on 9 August 1978.

The major topic of discussion was Inline Procedures.

A small amount of discussion of the allocation, et. al. from last meeting produced the consensus that in light of further investigation by Ed, parameterized definitions modules were the best solution so far.

First, the problem of neatly passing on a multiword return record from a called procedure was discussed. The favorite solution was to allow the new language construct of UNWRAP that turns a record into an expression list. Since there is no type in the language of expression list, it can only appear in special places. In fact, it can only appear in a RETURN list or an argument list of a call (i.e., a control transfer) and can only appear by itself. My notes don’t show whether it can be applied to an arbitrary record or just to the return record of a procedure. Some examples:

ip: PROCEDURE [...] RETURNS [a, b: Foo] = INLINE BEGIN . . . END;
xp: PROCEDURE [...] RETURNS [a, b: Foo] =

BEGIN
. . .
RETURN [UNWRAP ip[...]];--legal
END;

q: PROCEDURE [x, y: Foo] . . .
q[UNWRAP xp[...]];--legal

t: PROCEDURE RETURNS [a, b, c: CARDINAL];
f: PROCEDURE RETURNS [a, b, c, d: CARDINAL] =

BEGIN
. . .
RETURN [UNWRAP t[], x];--illegal
END;

a: ARRAY [0..4) OF CARDINAL ← [UNWRAP f[]];-- illegal

It was generally agreed that one should have to IMPORT a definitions module in order to get INLINE procedures from it. The current complaints from the compiler are considered more of a bug than a feature.

It was decided not to drop out bodies automatically for INLINE procedures when the programmer does a FORK, passes a procedure parameter, or recurs. After considerable discussion, a consistent position was taken that bodies are not automatically dropped out when a procedure is exported. Each of the above actions is disallowed for INLINE procedures.

The six cases of where an INLINE procedure is defined and called [1] were discussed. The cases are repeated below for your convenience.

CaseDefined in:Called in:

1definitionsdefinitions (same)
2 " "definitions (different)
3 " "program
4programdefinitions
5 " "program (same)
6 " "program (different)

Cases 1 and 5 are pretty non-controversial.

There was a discussion of hidden importation of interfaces through expansion of INLINE procedures. One outcome of this was the realization that definitions modules will need to have IMPORT clauses. Furthermore, in the presense of multiple instances of imported interfaces, the IMPORTS clause will have to be parameterized (in additions to the parameterization for types described above). Some examples might help.

Defs1: DEFINITIONS IMPORTS x: Defs2 =

BEGIN
. . .
s: PROCEDURE[...] = INLINE BEGIN ... x.q[...] ... END;
END;

Defs2: DEFINITIONS =

BEGIN
. . .
q: PROCEDURE[...];
r: PROCEDURE[...] = INLINE BEGIN ... q[...] ... END;
END;

Prog1: PROGRAM EXPORTS Defs2 =

BEGIN
. . .
q: PROCEDURE[...] = BEGIN ... END;
END;

Prog2: PROGRAM IMPORTS a: Defs1[b], b: Defs2, c: Defs2 =

BEGIN
. . .
a.s[...];-- calls b.q
b.r[...];-- calls b.q
c.r[...];-- calls c.q
END;

In the configuration file,

. . .
p1: Defs2 ← Prog1;
p2: Defs2 ← Prog1;
Prog2[NIL, p1, p2];-- since there is really no one who exports Defs1.
END;

The remaining discussion revolved around the question of how to access global variables in public INLINE procedures (cases 4 and 6). One suggestion was that a proposal from Peter Bishop be accepted wherein one could export variables as well as procedures and signals. This would allow cases 4 and 6 to go away, being replaced by the scheme of moving the variables to the procedures instead of putting the procedures with the variables. Several hack implementations were discussed with varying impact on the binder. Most seemed to use the standard procedure descriptor format and use the entry point number as either a global frame offset or as an index into an auxiliary table.

Further features of the proposal are the easier sharing of global data among modules (a mixed bag), and the possible elimination of the type POINTER TO FRAME. The mood of the working group at the end of the meeting seemed to be in favor of adopting such a scheme.

Bibliography

[1]Satterthwaite, Inline Procedures. August 1978.