Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site uiucuxc
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!pommert
From: pommert@uiucuxc.CSO.UIUC.EDU
Newsgroups: net.micro.mac
Subject: Coroutines needed for Macintosh!
Message-ID: <96900012@uiucuxc>
Date: Wed, 2-Oct-85 13:05:00 EDT
Article-I.D.: uiucuxc.96900012
Posted: Wed Oct  2 13:05:00 1985
Date-Received: Fri, 4-Oct-85 03:28:35 EDT
Lines: 79
Nf-ID: #N:uiucuxc:96900012:000:4456
Nf-From: uiucuxc.CSO.UIUC.EDU!pommert    Oct  2 12:05:00 1985


I just started writing my first (almost) Macintosh application on
my Lisa in Lisa Pascal.  I've gone to Mac Highschool and learned
how a Macintosh program is almost always structured.
(Initialization and then a loop which does a GetNextEvent,
processes the even, and then, perhaps, does a little background
work on the side.)  I began to port a simple graphics program from
Macintosh Pascal and discovered that it didn't fit very well into
the above mold.  The problem is that my program may take a very
long time to complete.  I don't want to freeze up my Mac until it's
done (which with certain parameters, could be days), so I will need
to every so often exit from my calculations and do another lap
around my GetNextEvent loop.  Okay.  That sounds doable at first
until I think of the structure of my calculations:  Procedures
calling procedures calling procedures doing graphics.  I will be
spending perhaps minutes in the inner most procedure.  I can tell
when I need to leave an check the event list but I will then have
to save the state of all of my procedures (with Pascal code),
leave, check the event queue, return, discover (by some flag) that
I'm not just starting but am continuing, climb through some very
hacky looking code, reinitializing all three procedures to the
state where I left off, and continue for a while.  Yuch!!!!!

I know many programming languages and have seen some features in
one or two of them which would solve my problem wonderfully.  (No,
unfortunately I am not as familiar with object oriented programming
languages as I would like.)  The feature that I'm thinking of is
coroutines ala Simula 67.  Coroutines are like procedures except
that in addition to being able to be called, they can also be
"resumed".  When a coroutine is called, it begins execution at its
beginning.  During its operation, it can RESUME  another coroutine.
If that coroutine has not been executed before, it will begin
execution at its beginning.  If it also has executed a RESUME, then
it will resume its execution right after its most recently executed
RESUME statement.  Coroutines usually don't fall off the end and
return as they do in Pascal, they just RESUME some other coroutine
instead.  What all of this buys you is the ability to have several
logically independant subprocessies which can temporarily give up
their control to other subprocessies.  (Actually, you can do many
more things with coroutines than this, but this is all that I want
to emphasize here.)  Another nice thing about coroutines is that
their activation record, or process state vector, remains until
either the coroutine does a return (say by falling off the end) or
until it is implicitly or explicitly destroyed (say by the job
terminating).

As you can see, if I had an implementation language which had
coroutines, my problem stated above would be solved very neatly, as
would many other programming problems on machines with
architectures similar to the Macintosh.

Since coroutines have lifetimes that are more independant than
procedures, their activation records must exist on the heap.  (That
is no problem: the latest version of Pascal for the Cyber 170
family got rid of the stack, as such, altogether and placed
everything on the heap, thereby eliminating many problems that it
was having.)  Because their lifetimes are arbitrary and their
activation records are on the heap, it makes sense to allow, as
Simula did, multiple instantiations of a given coroutine, each with
its own activation record (and coresponding process state).  If
this were allowed on the Macintosh, just think how easy it would be
to implement multiple window programs!  You would just create
another instantiation of the appropriate coroutine, point it to its
window, tie it into an overall stucture, and away you go.  You
would have to struggle with routines which have to keep track of
multiple windows anymore!

Any comments on all of this?  Coroutines are easily implemented.
(You have a position pointer which tells where execution should
begin (resume).  You do a RESUME by doing an indirect jump through
this position pointer.  You do a CALL by setting this position
pointer and jumping through it -- or you jump to an alternate entry
point which reinitializes the position pointer.)  Do object
oriented programming languages solve the problems that is have
stated ELEGENTLY and NEATLY?

	Daniel Pommert
	University of Illinois, Computing Services Office
	uiucuxc