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 <as...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
