This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> I don't follow this argument. (Actually, I can't follow a single step > of it.) Why does any low-level FFI automatically imply "a lot of > Scheme implementations which will not support it," and how is this > fact changed by having a high-level interface first? By "low-level" I mean an FFI that exposes the details of the implementation. Memory management can vary so much from one implementation of Scheme to the next that it is worthwhile to make the FFI abstract in this regard. An FFI where objects are converted automatically between Scheme and C (a "high-level" FFI) can eliminate nearly all memory management concerns (for the user of the system). A low-level FFI may be incompatible with a particular implementation strategy, and thus be very difficult to support (to the point that the implementor will not invest the effort to implement it, especially if this requires rewriting the whole memory-management system or if that implementation of Scheme already has a decent FFI, for example: PLT-Scheme, Chez-Scheme, Bigloo, and Gambit-C to name those I know best). In comparison, a high-level FFI can be supported with all internal memory management approaches that I can think of. So it is easier to implement in existing Scheme systems, and there is a higher likelihood that it will truly become a "standard" FFI. Marc