One of my former student researchers performed this work (Daniel Silva
supervised by Philippe Meunier). My rough impressions:
-- he tried three different approaches in roughly 2003-2005, the embedding
Racket into a C process seemed to work best
-- nothing worked perfectly at the time because of the impedance mismatch in
memory models and memory reclamation
-- our goals were strictly research-oriented (running #lang Python code via
the Python run-time and analyzing it)
[the Python community was so negative that my students lost interest]
-- the two implementations were integrated to the point where you could
exchange any data (though see memory)
and run some mutual callbacks.
-- I don't think it would be possible to have a general-purpose FFI but that's
my personal gut-feeling judgment
For Bassett's intentions this would work well from what I can tell though it
may not eliminate the actual performance bottleneck.
That's about all I can say -- Matthias
On Oct 4, 2013, at 2:49 AM, Andrews, Kyle (KC) wrote:
> Near the end of Matthew Bassett’s talk at RacketCon someone mentioned that
> the Racket developers had integrated Racket with python several times in the
> past. If so, what are the challenges towards creating a general purpose
> python ffi for Racket? As someone else who does a lot “guerrilla” Racket
> programming as an engineer in a large (non-software) company, it would be
> extremely pleasant to have easy access to the plethora of more standard
> scientific tools available there (and thus also to those available in R, and
> MATLAB, through libraries like RPy) for prototyping but without leaving the
> comforts of DrRacket.
>
> Kyle Andrews
>
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
____________________
Racket Users list:
http://lists.racket-lang.org/users
