On Mon, Sep 28, 2009 at 9:14 AM, John Cowan <[email protected]> wrote: > Joe Marshall scripsit: > >> So allow me to point at the existing Common Larceny implementation >> and suggest that an FFI should take that model into account. > > While I'm all in favor of such seamless FFIs (I'm still trying to work > out how to make a seamless FFI on the JVM without reflection), I think > that C FFIs and JVM/CLR FFIs are such totally different things that they > ought not to be conflated. If it makes no sense for a Scheme system > to offer a C FFI, it shouldn't offer one; but that said, most systems > are embedded in a C rather than a JVM or CLR world, and standardizing > a C FFI, at least on the Scheme side, makes a great deal of sense to me.
The difference between the two is that the JVM or CLR has a substantial amount of metadata that allows you to inspect the ABI in addition to just calling it. When the metadata is missing, you have to supply it manually somehow. Scheme is not the only language with this problem, nor is it a pioneer in the solution space. Interlanguage interop has been done over and over (and over) since the 80s so it makes sense to use what has already been developed rather than yet another ad-hoc mechanism. An IDL -> Scheme compiler would be a great start. > As has been noted on another thread, CL has a C FFI that is quasi-standard. > I've tried to look into it but have so far failed; I'll give it another > shot. > >> Error handling, memory management, object representation, metadata sources, >> type conversion... Call/cc is pretty straightforward, actually. No ABI >> that I am aware of would permit a re-entrant continuation, so putting >> the appropriate barriers at the transitions ought to take care of that. What >> is harder is unwinding the scheme stack when the foreign function >> does a longjmp. > > In Chicken, at least, that's impossible: doing a longjmp will corrupt > Scheme data, because the C stack just is the nursery part of the Scheme > heap. Obviously you'd evacuate the stack before actually performing the longjmp! -- ~jrm _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
