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.) Marc> In my experience, a high-level FFI that only supports basic types Marc> common to C and Scheme (numbers of various precisions, Booleans, Marc> characters, nonnull-strings and possibly-null-strings, and Marc> null-terminated arrays of strings) is sufficient for most Marc> applications. felix> > >> In my experience, it isn't. felix> > felix> Great. With this style of discussion we are getting nowhere... Now, I've promised myself to not even reply to this kind of trollery anymore, but here I go again ... 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.) 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. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla