[plt-scheme] handle-evt can wrap handle-evt

From: Robby Findler (robby at cs.uchicago.edu)
Date: Thu Feb 22 00:02:09 EST 2007

On 2/21/07, Dimitris Vyzovitis <vyzo at media.mit.edu> wrote:
> On Wed, 21 Feb 2007, Robby Findler wrote:
>
> > On 2/21/07, Dimitris Vyzovitis <vyzo at media.mit.edu> wrote:
> > > On Wed, 21 Feb 2007, Robby Findler wrote:
> > >
> > > > > The point is to disallow (handle-evt (handle-evt ...) ...)
> > > > > That's what Matthew meant (I think :) and I don't see any error to it.
> > > >
> > > > Matthew's "error" is only that he says that the above should be an
> > > > error in Scheme! :)
> > > >
> > > > I'm saying that it should not be an error. I think it is useful and
> > > > should not be disallowed.
> > >
> > > If it is allowed how is it different from (handle-evt (wrap-evt ...) ...)?
> >
> > The break-handling state won't change (which is important sometimes;
> > generally you don't to disable breaks very often and when you do, you
> > should be careful about).
>
> Actually it might depending on how and with what the nested handler syncs.
> But it doesn't by default.
>
> >
> > Also, you don't have to plan ahead to use wrap-evt if you think
> > someone else might want to use handle-evt.
> >
>
> Well, you still have to plan to evaluate to an event.
>
> > > I think that the intent is 'handle-evt proc is a handler that is in tail
> > > context wrt sync'. This cannot be guaranteed when handle-evts can be nested.
> >
> > Right. I believe this is a bogus claim. It should be weakened to only
> > apply when there is a single handle-evt.
> >
> > (when Matthew and I first discussed this as it was being implemented I
> > didn't realize it was too strong. I'm glad you pointed this out.)
> >
>
> Perhaps there should be a third class of event wrapper that is tail
> wrap-evt without break disabling (weakly tail handle-evt)?
> This could allow both the stronger guarantee of enforced tail handle-evt
> and the non-break altering behavior for nested event generating loops. It
> also provides for a cheaper alternative to wrap-evt that doesn't mess with
> the break state.

That sounds like it would just be handle-evt but with Matthew's proposed check.

Robby


Posted on the users mailing list.