[racket] TR: struct: #:prefab option

One final point a TR problem I ran into something similar with regards to
dynamic require.  I can'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.

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. ;)

---> In other words I'm good with #:prefab being dropped. <---

Not a show stopper.

Thanks,

Ray


On Mon, May 6, 2013 at 1:45 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:

> On 2013-05-06 13:40:08 -0400, Ray Racine wrote:
> >    Not sure I follow. If one uses a typed function imported into untyped
> >    Racket all bets are off.
>
> In your example, a contract error is raised, so you can pin the blame on
> the untyped code and you're "safe" (e.g., no memory corruption).
>
> In the example I gave, the misuse from the untyped module actually
> violates safety and you get potentially arbitrary behavior. I'm sure it
> would be easy to cause a segfault instead of just producing a nonsense
> numerical result.
>
> Cheers,
> Asumu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130506/0982d08b/attachment.html>