[plt-scheme] escape continuations and mred callback

You're right -- calling the show method (with #t) on a dialog calls
`yield' which does what you describe, but to make event handling
uniform, it always has a barrier (at least I guess that's why).

Robby

At Sat, 7 Oct 2006 21:27:25 -0500, "pedro pinto" wrote:
> OK, I finally see what you mean, I assumed that when I called (send dialog
> show #t), the program would enter a loop that plucks messages out of the
> dialog event queue and dispatches them *synchronously* to the appropriate
> callbacks. A small test I did indicates that no event dispatch occurs while
> a callback is beinghandled, so at least the dispatch does appear
> synchronous. So, in theory at least, for my particular example, I think an
> escape continuation could still take me out of a callback and back into my
> own code.
> 
> As you point out however in the non-modal case, there must be a message
> loop, or watch dog,  running on another process and in that case I suppose
> invoking the escape continuation would replace the watch dog stack with the
> one on my original process, and, since I suspect there is only one watch dog
> for all the windows in the application, kill all UI updates. I can see why
> there would be need for a continuation barrier.
> 
> Does this make any sense, or I am totally of base here?
> 
> Thank you for your patience,
> 
> -pp
> 
> 
> On 10/7/06, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
> >
> >
> >
> > No you didn't. A callback doesn't return and can't return. It is an
> > asynchronous call from somewhere deep inside when an event occurs. In
> > a sense, it is run in concurrently to the rest of the program. In
> > your special case, it was waiting (due to the modal dialog) and one
> > could argue that there is a sequential flow of control. But that's
> > just a special case.
> >
> > So, in general, some concurrent process watches the "world" and waits
> > for events to happen. When they do happen, it checks whether you want
> > to know about it. This watch dog finds out that you have installed a
> > callback and calls. If you raise an exception, the exception erases
> > the control stack of this call and everything around it. In other
> > words, it stops the execution of the watchdog process. Now your own
> > process is spared. After all, there is no connection between the
> > watchdog and your application.
> >
> > This has little to do with the fearsome first-class continuation
> > objects in Scheme but everything with "GUI concurrency" and
> > "exceptional flow of control."
> >
> > Since callbacks can't return, they have void as a return type. You
> > are therefore forced to communicate all results and values across
> > this "void wall" via side effects.
> >
> > ;; ---
> >
> > If you really want to dig deep: all this is the fundamental flaw of
> > call-back based programming. It's the dominant and efficient model. I
> > sure wish, however, we could come up with something better.
> >
> > -- Matthias
> >
> >
> >
> >
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme