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

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.

-- vyzo