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