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.
<br><br>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.
<br><br>Does this make any sense, or I am totally of base here?<br><br>Thank you for your patience, <br><br>-pp<br><br><br><div><span class="gmail_quote">On 10/7/06, <b class="gmail_sendername">Matthias Felleisen</b> <
<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>No you didn't. A callback doesn't return and can't return. It is an
<br>asynchronous call from somewhere deep inside when an event occurs. In<br>a sense, it is run in concurrently to the rest of the program. In<br>your special case, it was waiting (due to the modal dialog) and one<br>could argue that there is a sequential flow of control. But that's
<br>just a special case.<br><br>So, in general, some concurrent process watches the "world" and waits<br>for events to happen. When they do happen, it checks whether you want<br>to know about it. This watch dog finds out that you have installed a
<br>callback and calls. If you raise an exception, the exception erases<br>the control stack of this call and everything around it. In other<br>words, it stops the execution of the watchdog process. Now your own<br>process is spared. After all, there is no connection between the
<br>watchdog and your application.<br><br>This has little to do with the fearsome first-class continuation<br>objects in Scheme but everything with "GUI concurrency" and<br>"exceptional flow of control."
<br><br>Since callbacks can't return, they have void as a return type. You<br>are therefore forced to communicate all results and values across<br>this "void wall" via side effects.<br><br>;; ---<br><br>If you really want to dig deep: all this is the fundamental flaw of
<br>call-back based programming. It's the dominant and efficient model. I<br>sure wish, however, we could come up with something better.<br><br>-- Matthias<br><br><br><br></blockquote></div>