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.
> From: felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> I'm a little lost in the layers of quotes here but: > Note that the Chicken FFI (for example) does not allow GC during the > invocation of foreign code, unless callbacks are explicitly used, > and that all arguments are normally passed as valid C data (i.e. > C code is provided a "view" of the data that it can understand, > similar to what I proposed). It has been useful enough to write > wrappers for OpenGL, GLUT, BLAS, SQLite, the Irrlicht 3D engine, > Sockets, most of POSIX, JAPI, MD5 stuff, Tiny CC, PCRE, SDL, GMP, > SCOP, Spread and many other things, which should be enough for > the start... Do I understand correctly if I restate things this way?: There's a bunch of useful C libraries to expose to Scheme. Generally speaking, those libraries have implicit "semantic models" that are explainable as a narrow, tastefully selected construct built out of C semantics. For example, their parameters come from a fairly simple domain of types, their flow of control is simple, and so forth. A common use of an FFI for some high-level language is to expose such C libraries in the high-level language. One approach to this, that taken by the draft, is to make an FFI that models a substantial part of the semantics of the high-level language -- then let the FFI-using programmer fill in the gap between that and our target libraries. Another approach, that proposed by Felix (if I'm reading right), is to make an FFI that captures the semantics of the libraries in a first-class way -- then let the FFI-_implementing_ programmer fill in the gap between that and his high-level language implementation. As an illustration of the difference: I _vaguely_ recall that some GL calls take as input a sequence of vertexes. In the draft-FFI approach, we would say "Well, scheme will hand you a list or vector of triples or quads of Scheme numbers. From there, you can construct a sequence that fits the calling conventions of GL." In the alternative approach, we would say "Here's an FFI that let's you describe the kinds of sequence that GL calls expect (perhaps it's an arbitrary-sized array of 3-element arrays of `float' values). And to you Scheme implementors: you need to provide functions to convert between lists or vectors and those C types." I think it's true that the alternative can be a very effective approach. What I'd like to see is the model of C interfaces that we'd like to be able to model. The model has to include how it maps into Scheme, too: <library to bind (e.g. GL)> ^ | v (ffi description of GL interface) [a] ^ | v (ffi implementation for particular scheme implementation) ^ | v <some scheme implementation> ^ | v <portable use of the binding> [b] An alternative ffi spec would have to say how to write [a] and [b]. -t