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.

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.

Chicken also distinguishes between three kinds of C procedures: ordinary
C procedures (declared with "foreign-lambda") that cannot call Scheme
procedures or allocate Scheme objects, fairly ordinary C procedures
(declared with "foreign-safe-lambda") that can do those things, and C
procedures (declared with "foreign-primitive") that are on all fours
with compiled Scheme, can do anything, and call their continuations
rather than returning.

-- 
So they play that [tune] on                     John Cowan
their fascist banjos, eh?                       [email protected]
        --Great-Souled Sam                      http://www.ccil.org/~cowan

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to