On 28 Sep 2009, at 1:53 pm, Shiro Kawai wrote : >> I think there's a good cause for standardising a basic minimal- >> assumptions FFI and having implementation-dependent extensions beyond >> that, yes. > > I also agree that minimum Scheme-side interface may be > defined portably. (The withdrawn srfi-50 tried to define > C-side API as well, but that opened huge can of worms.) > > Whether it needs to be in the standard or not is another > question. I feel SRFI can do the job, but it may worth > to discuss the possibility here.
Yes, I think it's more of a topic for an SRFI, too. >> 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). > > How it is implemented can be left to each implementations. > What matters is API. Yeah, I mean to provide an API exposing that sort of model. Something like: (define (my-lib (ffi-link "libc.so"))) ; can of worms #1: that library path string! (define (my-func (ffi-lambda my-lib float "sin" ((float x))))) (my-func pi) => 0.0 > Some systems expose foreign function names differently > (e.g. whether prepending '_' or not). We might need to > standardize the interpretation of the foreign function > name. (This leads to the question of C++ mangled function > names, which I don't want to think about...) Mmmm. Let's stick to referencing the platform's C linking semantics for now! [call/cc] Yes that sounds a good baseline semantics IMHO. > What can't be left out from "minimum interface" is heap > management, since not all implementations are possible > to manage it completely automatically by the host GC. Yes. The worst case would require all memory touched by the FFI to be copied to/from the heap explicitly. And anyway, who says what internal representation a string or srfi-4 vector or blob might have in the Scheme world? > (1) Passing a Scheme object to a foreign entity (including > callback closures): For portability, we should assume we > can't know when the foreign entity drops the reference to the > Scheme object. A pragmatic approach is that the FFI > implicitly protects all objects that passed to the foreign > functions, and requires application code to unprotect them > explicitly. Yeah, I think JNI does something like that. It might be good to take a look at JNI, which is an existing serious stab at a cross- implementation FFI for a standardised language; I've no idea how well it fulfills the requirement, though! http://en.wikipedia.org/wiki/JNI [issues of boxed foreign objects snipped] Agreed. > > --shiro > 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
