David Rush scripsit: > "C FFI" is a misnomer. Try "Native ABI", which exists in a JVM world > (JNI) , the CLR (as unmanaged code), and most every other platform > imaginable. I did neglect to consider the implications of a VM FFI, > but that is frequently addressed through system binding conventions > (e.g. java-dot notation).
JNI, though, has absolutely nothing to do with Scheme, and it's an example of an FFI of the first kind: you write very peculiar (and slow) code in C as glue. Furthermore, I don't know of any JVM Scheme that allows access to native methods (ones implemented using JNI) except through the medium of Java. So what you have is a Java FFI for Scheme accessing a C FFI for Java. The result looks to the Scheme like Java, not like any kind of C. In short, a standardized C FFI, using the types, functions, and variables of C, makes sense only in a Scheme embedded directly in C. I don't know anything about the managed/unmanaged code interface on the CLR, so I can't comment on that. > > A C standard FFI interface, on the Scheme level, would make a good > > SRFI. It's not relevant to the standardization process of Scheme > > itself, though. > > Since I started the thread, I am inclined to disagree. SRFIs have > a different compliance-nature than the Reports. And *every* Scheme > implementation I have seen has a native ABI of some description, even > if you have to recompile the interpreter to use it (e.g. SIOD). Since > it is a feature of every implementation it *should* be standardized > so that we can actually rely on it. I can't see a standard FFI that usefully hides the distinctions between Java, C#, and C. Of course, if you care to sketch one, I'd like to see it. -- In my last lifetime, John Cowan I believed in reincarnation; http://www.ccil.org/~cowan in this lifetime, [email protected] I don't. --Thiagi _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
