<div dir="ltr">Probably we just didn&#39;t consider that! It does seem better.<div><br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 1:06 PM, Asumu Takikawa <span dir="ltr">&lt;<a href="mailto:asumu@ccs.neu.edu" target="_blank">asumu@ccs.neu.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-07-25 12:55:25 -0500, Robby Findler wrote:<br>
&gt;    I think the issue is that the tail guarantee can&#39;t be met if there are two<br>
&gt;    handles (one won&#39;t be in tail position wrt to the sync).<br>
<br>
</div>I understand. I guess what I&#39;m asking is that there seem to be two<br>
reasonable choices for the semantics here:<br>
<br>
  (1) Do not allow an event that is created as a handle event to<br>
      ever have two handlers.<br>
<br>
  (2) If an event ever ends up having two handlers, that&#39;s okay, but<br>
      it will not respond #t to `handle-evt?`.<br>
<br>
My question boils down to &quot;why semantics (1) and not (2)?&quot;<br>
<br>
(though it doesn&#39;t matter much if we just choose not to reflect<br>
 this in the type system, but that means you will sometimes<br>
 get a contract error saying &quot;expected (not/c handle-evt?) but ...&quot;)<br>
<br>
Cheers,<br>
Asumu<br>
</blockquote></div><br></div>