On 28 Sep 2009, at 10:59 am, David Rush wrote: > I've been doing a lot of FFI work in Scheme lately, and it's finally > gotten me to wondering: Is there any good reason to *not* have a > standard FFI in Thing2?
I think there's a good cause for standardising a basic minimal- assumptions FFI and having implementation-dependent extensions beyond that, yes. In particular, everything from compiled to interpreted implementations should be able to wrap dlopen + libffi, on platforms that support that. And even embedded platforms can "fake" dlopen + libffi, by having a hardcoded table of statically-linked-in C libraries that you can magically dlsym() things out of, should they wish to. > I do realize that there are legitimate questions w/rt an FFI that may > not be easy to codify - interaction with CALL/CC being among the most > obvious - but declaring type mappings and calling conventions for > native ABI functions seems fairly straightforward and easily > represents a 90% of the work that needs to be done kind of solution. I think the complex issues are: 1) How to get at the foreign functions in the first place. I suggest dlopen+libffi as that is fairly universal across implementation techniques, compared to statically linking code in (which may be painful in an interpreter). 2) What to do abut the heap and call/cc 3) How to handle callbacks back into Scheme (which is really the tricky case for call/cc :-) 4) How to handle C++ classes and the like, and access to C-compiler features like macros (some libraries aren't very amenable to dlopen() as they really expose a set of macros that expand to funnily-named symbols, or to dereferences through a struct of pointers, or whatever). This usually requires writing a stub in C and linking that in, or in Chicken, taking advantage of it being a Scheme->C compiler by writing inline C in your Scheme. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
