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> How come? What do you mean with "in the way"? Perhaps your felix> particular high-level interface is insufficient? It's not about sufficiency. (Even though both you and Marc admitted that your particular high-level FFI proposals can only handle most of what may be needed.) It's about appropriateness. When I'm using C headers to generate FFI information, it seems silly to convert the C types to their Scheme representation, only to convert them back again. (Arguably, the conceptual overhead of representing C types in Scheme implies that this isn't such a great way of going about linking in C libraries, after all.)
AFAIK both Marc and me did not propose FFI-generating headers. But, anyway, I still don't see the problem. A FFI that keeps the programmer oblivious of the implementation-specific data representation and GC strategy is simply a must, if it is supposed to be portable - there is no way around it. The preceived "sillyness" of converting data between Scheme/C representations sounds unconvincing. There is an abstraction barrier that we have to accept and the performance implications are (IMHO) secondary.
Now, I've promised myself to not even reply to this kind of trollery anymore, but here I go again ...
Yes, go ahead...
You know the list of FFI bindings I've been involved in; among them two generations of scsh with full POSIX access (which someone called "low-hanging fruit" earlier in the discussion.)
Michael, these pissing matches over who has the most experience are rather inappropriate in a technical discussion as this one. Your experience may be vast (I can't tell), Marc's experience may be as well (I can't tell either). I assume most people on this mailing list have some, so why don't we just forget about that and try to find better arguments instead.
But you don't have to take my word. I invite you to look at Subversion, one of the few projects that has C FFI bindings for multiple language implementations, and look at how much effort these folks need to spend on the implementation-specific type conversion functions.
But type conversions have to be done anyway! Wether you convert the data automatically (hidden in implementation-specific constructs and wrappers), or explicitly makes no difference. Only that the automatic conversion (and I'm *not* talking about header-file munging - I'm talking about implementation-specific glue code) is the only way of making it portable. cheers, felix