Sunday, June 29, 2008

Al learns more CS crap, has an idea.

Friday at work I learned what continuations and coroutines are. All you CS weenies can make fun of me now. Go design a hardware interface and then come back and make fun of me more.

I've also been doing some GUI programming in the common event-driven style, and wondering if this is really the best way to do it. If you're writing a typical program for the console overall program flow comes very straightforwardly from the code. If it's time to get some input from the user you can just call a subroutine with some scanfs in it. If there are temporary variables needed for this you declare them in this subroutine and they go out of scope when you're done. In event-driven programs you have to keep track of your flow with mode variables, and put giant switches in event handlers. If there's some data you need temporarily for input but has to persist across a few events (say, while the mouse is dragging out an area) you'll either make it a member of an object that will be around much longer than needed or else have to allocate and destroy it manually. We try to hide some of this behind libraries of pre-fab components, but that doesn't make it go away.

To me it makes a lot more sense that the routine you're executing has to do with the task you're performing, and to switch over the possible events that might occur, as in a command-line program. And when Matt Elmer told me what a coroutine was, and then I looked up continuations, it just clicked that this is how GUIs can act like console apps. When the user starts dragging an outline, generating a mouse-down event, call an inputOutline function. Temporary dragging state is automatically allocated on the stack. You yield to the system and pass your current continuation. The system calls this continuation when an event occurs, passing in event info, and then comes your switch over events that make sense at that time. Ultimately you probably wouldn't want to deal with bare continuations I guess. And it seems like program flow might get either inflexible or overcomplicated.

Does anyone know if this sort of thing has been done? Or if it's been tried and encountered serious problems? I can't seem to find anything similar, and I am probably not a good enough GUI programmer at this point to implement it. Also I am slow, lazy, and spend lots of time running and writing music badly. Maybe I could do it as a LISP project someday.

1 comment:

Anonymous said...

coroutine is a pretty word.

i just put .net on my work computer! and i am to learn either visual basic or c#!

... and i'm not sure if i should follow that with "please don't hate me" or not... some people seem pretty adament against and i wanted to gauge yr opinion.