[racket-dev] Motivation for handle-evt/wrap-evt contracts

My thought was that you should only use `handle-evt' if you need tail
behavior for something like a loop. If you use `handle-evt' and you're
not getting tail behavior (but `sync' continues on, anyway), then
something has gone wrong --- and maybe it's better to get an error than
have a slow leak that will be tricky to detect.

We don't generally try to declare tail behavior and detect non-tail
behavior, so maybe it wasn't a good idea in `handle-evt', but that was
the motivation.

At Thu, 25 Jul 2013 13:23:27 -0500, Robby Findler wrote:
> Probably we just didn't consider that! It does seem better.
> 
> Robby
> 
> 
> On Thu, Jul 25, 2013 at 1:06 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:
> 
> > On 2013-07-25 12:55:25 -0500, Robby Findler wrote:
> > >    I think the issue is that the tail guarantee can't be met if there
> > are two
> > >    handles (one won't be in tail position wrt to the sync).
> >
> > I understand. I guess what I'm asking is that there seem to be two
> > reasonable choices for the semantics here:
> >
> >   (1) Do not allow an event that is created as a handle event to
> >       ever have two handlers.
> >
> >   (2) If an event ever ends up having two handlers, that's okay, but
> >       it will not respond #t to `handle-evt?`.
> >
> > My question boils down to "why semantics (1) and not (2)?"
> >
> > (though it doesn't matter much if we just choose not to reflect
> >  this in the type system, but that means you will sometimes
> >  get a contract error saying "expected (not/c handle-evt?) but ...")
> >
> > Cheers,
> > Asumu
> >
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev