The author starts with some critical comments on the BCPL coroutine primitives described by Moody and Richards [1]. Without discussing what he considers the desirable properties to be achieved, Fisher immediately introduces his own low-level set. The basic means of transferring control is the routine SWAPCO(), which has no arguments and resumes an unspecified different coroutine. This set he calls “unguarded coroutines.” They make no provision for the passing of values between coroutines, so some primitives for “guarded coroutines” which allow this--CALLCO and ACCEPTCO--are defined in terms of them. The specifications are curious, in that they require coroutines to unnecessarily pass their own identities as parameters; even determining these identities requires an awkward use of side-effects. The routines are implemented in terms of an inelegant sort of “busy waiting” on global variables. They are called “guarded” because they guard the coroutine from being resumed at an appropriate time, but the very choice of terminology suggests a view of coroutines as being overly concerned with transfers of control rather than of data. We are told that it is normal to follow CALLCO immediately by ACCEPTCO, which itself suggests that the primitives seen by the user are not ideally chosen. No justification for preserving both unguarded and guarded coroutine facilities is given.

Two useful primitives, PUSHCO and POPCO, provide a bracketing around sets of cynamically created coroutines and allow the subsequent deletion of whole groups of coroutines extremely easily. They are a good addition to the Moody and Richards set.

The only example program given is a poorly described treewalking program which uses another primitive, NAMECO, which is only introduced later, and then inadequately. A section on applications makes tantalizing reference to their use in solving some tricky problems in an ALGOL68 compiler, but too sketchily to be very enlightening.

The whole paper would have benefited greatly from more general considerations of what are the strengths and weaknesses of different views of coroutines, before defining yet another one. Even one of the advantages claimed here, that no stack size needs to be specified when a coroutine is created, turns out to depend entirely on the underlying operating system.