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.
"Felix" == felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:Felix> My idea is simpler, more safe, more portable and does away with most GC Felix> and character-representation issues (as far as I'm able to understand Felix> Unicode-related problems): define blocks of code externally, with a Felix> properly defined set of arguments/results and their types. The foreign Felix> bindings could be defined in a "binding"-language, perhaps even by takingFelix> ideas from SRFI-7: While this approach is very seductive, my personal experience (stemming from writing or supervising the writing of) many, many lines of C bindings and investing considerable thought and work into this kind of thing, is that it's neither simple to implement, nor general enough to address even a significant portion of the C binding needs out there in the real world. For a comparatively small example: scsh had something like this once (called CIG), which we largely did away with it for the 0.6 series precisely because it tended to make things harder rather than easier. Moreover, this kind of approach still doesn't absolve you from specifying what the C-level interface with Scheme looks like. See, say, SWIG for an example where "the simple approach" was used in the beginning, and then more and more half-baked stuff was stapled and Scotch-taped on later. This kind of thing could still be very useful, mind you, but it doesn't meet with the stated goals of this particular SRFI.
Hm, you probably misunderstood: I'm not talking about making a SWIG-like FFI-tool mandatory, I merely defined a language (quite similar to the approach taken by SRFI-7), that specifies blocks of foreign code, plus the types of the argument and result values. How exactly this is processed, or wether an external tool is used, is not relevant. The problem I see with the current SRFI-50 draft is that it will lead to extremely subtle and hard to find bugs, because too much implementation specific knowledge is implicitly expected from someone using the FFI. cheers, felix