pommert@uiucuxc.CSO.UIUC.EDU (10/02/85)
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
pommert@uiucuxc.CSO.UIUC.EDU (10/04/85)
A number of people responded to my base note in person. Their suggestion was as follows: put the main event loop in a procedure and call it from inside the calculating routine, making sure to dim out any menu item which would allow you to start the computational portion up recursively. I agree that in the simple case that this would work and would be reasonable easy to implement. (As I shall comment below, I think that it is one of the two best ways to solve this problem without leaving Pascal.) The part that I don't like about it is that the procedure nesting structure/data structures do not shadow what is going on logically in the program. Therefore, I will need to pass back flags from this routine to the calculation procedure telling it such things as it needs to stop, rescale some data, and so on. There are bigger problems if I tell it that I want to bring up as separate window to display some global results of the calculations performed so far. Maybe I could keep it simple, but I fear that this approach would just lead to a tangled mess. In speaking with Steve Peltz (author of MacPad, Plato terminal simulator) who is familiar with the Lisa Workshop and Lisa Operating System, we were both saying that the Macintosh needs is the ability to do multiprocessing. Then I could fire up a computational process, have my GetNextEvent loop process running, and fire up any other processes that I would need. I could suspend processes as would be necessary, twiddle with parameters (ideally through calling procedures supplied as entry points to that process), et it running again, restart it, or kill it. (Oh, for a good 68020 based operating system!) In summary, this proposed method of dealing with a computationally bound function is a good-as-can-be-helped work around, but perhaps not great in general. My original method would probably work out better for complicated logical processes structures, each with a relatively simple structure. These are the only two good solutions that I can think of while programming in a primative language like Pascal or C. A better solution would be a proper implemetation of coroutines. I believe that the best solution would be multitasking with proper hardware (68010 minimum) and software support. Daniel Pommert Computing Service Office University of Illinois at Urbana-Champaign pommert@uiucuxc.cso.uiuc.edu puree|uiucdcsa|uiucuxc|pommert
abdali@tekchips.UUCP (Kamal Abdali) (10/05/85)
------------------------------ > > 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. > > Daniel Pommert Modula-2 contains coroutines as an important language feature. Coroutines seem to work well in MacModula by Modula Corporation, Provo, Utah. Although I haven't yet tried the public domain ETHZ Modula-2 on a program containing coroutines, I take it for granted that that compiler also supports coroutines. S. Kamal Abdali Tektronix, Inc. Beaverton, OR 97077
bobc@tikal.UUCP (Bob Campbell) (10/06/85)
In article <265@tekchips.UUCP> abdali@tekchips.UUCP (Kamal Abdali) writes: >Provo, Utah. Although I haven't yet tried the public domain >ETHZ Modula-2 on a program containing coroutines, I take it for >granted that that compiler also supports coroutines. You shouldn't, as it does not support coroutines (it is a feature which can be added by rewritting the SYSTEMX module), I tried it and discovered that it produces indirect calls to HALT. This does not mean that coroutines can not be supported, but it appears that they were removed from the mac implementation as the Generic 68K compiler used the user mode stack pointer (as apposed to the supperviser), and the mac stack sniffer has to be turned off. Bob Campbell {fluke,uw-beaver}!tikal!bobc Teltone Corp. PO Box 657, 10801 -120th Avenue NE Kirkland, Washington.
gus@Shasta.ARPA (10/07/85)
> > 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!!!!! AH! A fellow Lisa Pascal user. Welcome. It seems like you could use a multi-tasking package (with pipe capability) which was offered as part of the software supplement. I don't think that it is in the latest release but it is certainly available in earlier releases. (You DO keep the old disks don't you?) The routines are on one of the Lisa workshop disks and all have prefix serial/ or pipes/. There is no printed documentation and I cannout vouch for their stability, but they might just do the job for you. Gus Fernandez
thomas@gmdzi.UUCP (Thomas Gordon) (10/07/85)
I don't know if coroutines would solve your problem, but Modula-2 offers them. There are at least 2 Modula-2s for the Mac. One, from ETH in Zurich, is a 68000 native code compiler. Tom Gordon thomas@gmdzi.UUCP -- Tom Gordon thomas@gmdzi.UUCP
tesler@apple.UUCP (Larry Tesler) (10/08/85)
In general, object-oriented languages do not provide coroutine-like facilities. Some, like Simula-67 and Smalltalk, do. If coroutines are provided, they work out neatly, because the object's state is better protected than in an ordinary programming language (albeit not as well as with a MONITOR).