James Bielman wrote:
> I've been thinking about doing something like this as well (although
> looking at other embeddable non-Lisp languages like Ruby and
> Javascript too), as I have a need at work for allowing non-Lisp
> programmers to write extensions to a large CL program in a language
> they are familiar with.
Sounds interesting.
> It should be possible to make fancy use of CFFI type translators to
> automatically convert Lisp values to and from Python when calling and
> returning.
Yes, that would be quite neat, and not too hard.
> I also want to be able to define Python classes and
> functions in Lisp---more of a Python bridge, I suppose. In my case, I
> would also need to be able to initialize multiple Python runtime
> contexts in different threads---I'm not sure if Python can do
> that(?)...
I once tried starting PyRun_SimpleString (the eval function) from
different threads when I was using Python with a C++ program, but I
can't remember what happened.
> I started down this road with the Mozilla Javascript interpreter a few
> weeks ago but got irritated when I realized how much of the public
> interface was defined in terms of C macros (same problem with Ruby
> IIRC).
Thankfully, all (!) Python insists on are:
*An array of structs that each contain a function pointer, terminated
by a struct full of NULLs
*The functions to get arguments and return them, both take C-style
variable arguments (uncertain stack size)
*Just one macro though, which maps InitModule4 to versions with less
arguments
Ah well, I suppose they tried to make it as hard as possible for anyone
trying to call Python from FFI (in the generic sense). ;-)
Cheers,
Jeremy.
--
| Jeremy Smith BSc (Hons)
| Chief Scientist, Decompiler Technologies
| Member, British Computer Society
| England
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
