[plt-scheme] escape continuations and mred callback

On Oct 7, 2006, at 12:55 PM, pedro pinto wrote:

> I understand the callback is called from somewhere in the bowels of  
> the MrEd code, after a GUI event has been extracted from the UI  
> message queue. I also can imagine that escaping from the callback  
> will prevent some resource cleanup, but I interpreted your original  
> email as hinting at something fundamentally wrong with escaping  
> from *any* callback. Maybe I misunderstood?

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






>
> -pp
>
>
> On 10/6/06, Matthias Felleisen <matthias at ccs.neu.edu> wrote: Every  
> function is called from some place, right? So think of your
> callback function. It must be called from some place. That is also
> the place where it returns to. QUESTION: Where is that?
>
> -- Matthias
>
>
>
> On Oct 6, 2006, at 8:06 PM, pedro pinto wrote:
>
> > I am sorry, this continuation stuff makes my head spin. I
> > understand the barrier idea but I don't understand the motivation.
> > A callback is just another function, why is it barred from escaping?
> > -pp
> >
> >
> > On 10/6/06, Matthias Felleisen <matthias at ccs.neu.edu> wrote: There
> > is a built-in barrier -- a delimiter of control -- around
> > callbacks. If you think about it, it's quite obvious. A callback
> > doesn't return. But at the same time, all functions do return
> > somewhere. Well the place that is invisible and unavailable to  
> you is
> > somewhere in the system. And right around this call site there is a
> > barrier for all escapes. -- Matthias
> >
> >
> >
> > On Oct 6, 2006, at 7:19 PM, pedro pinto wrote:
> >
> > > Hi there,
> > >
> > > Shouldn't this:
> > >
> > >   (require (lib "class.ss")
> > >            (lib "mred.ss" "mred"))
> > >
> > >   (define (go)
> > >     (let/ec return
> > >       (let ((f (new dialog% (label "Hello"))))
> > >         (new button% (parent f)
> > >              (label "Me, Me!")
> > >            (callback (lambda _
> > >                        (send f show #f)
> > >                        (return "Escaping"))))
> > >         (send f show #t)
> > >         "Did not Escape")))
> > >
> > >   (go)
> > >
> > >
> > >
> > > Evaluate to "Escaping" when the user clicks the "Me,Me!" button?
> > >
> > >
> > >
> > >
> > > _________________________________________________
> > >   For list-related administrative tasks:
> > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>