<div dir="ltr"><div><div><div>One final point a TR problem I ran into something similar with regards to dynamic require.  I can&#39;t remember all the details, but the issue had to do with dynamic requiring a module in TR and casting the exposed function(s).  Details escape me at the moment.  I think I ended punting on that one or dropping in regular R for the section of code.<br>
<br></div>Also in the code I posted you can see in the comments I as eventually targeting a binary format serialization anyway.  Using #:prefab was just a temporary measure, it seems I now have impetus to tackle that now. ;)<br>
<br></div>---&gt; In other words I&#39;m good with #:prefab being dropped. &lt;---<br><br></div>Not a show stopper.<br><div><br>Thanks,<br><br>Ray<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 1:45 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-05-06 13:40:08 -0400, Ray Racine wrote:<br>
&gt;    Not sure I follow. If one uses a typed function imported into untyped<br>
&gt;    Racket all bets are off.<br>
<br>
</div>In your example, a contract error is raised, so you can pin the blame on<br>
the untyped code and you&#39;re &quot;safe&quot; (e.g., no memory corruption).<br>
<br>
In the example I gave, the misuse from the untyped module actually<br>
violates safety and you get potentially arbitrary behavior. I&#39;m sure it<br>
would be easy to cause a segfault instead of just producing a nonsense<br>
numerical result.<br>
<br>
Cheers,<br>
Asumu<br>
</blockquote></div><br></div>