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: Jim Blandy <jimb@xxxxxxxxxx> > Tom Lord <lord@xxxxxxx> writes: >> Between character issues, string and string index issues, >> no-reasonable-way-to-support-writable-shared-strings/vectors, >> and so on -- it seems clear to me that a portable FFI is never >> going to be able to compete with a native FFI for some tasks. > Gee, that's not clear to me at all. I think the SRFI-50 text as > proposed is a very useful thing. It has two problems I'd like to see > solved: > - As proposed, SRFI-50 constrains the system to be single-threaded, or > at least to collect only when all threads are at safe points. > - There's the issue of how to give the result of SCHEME_EXTRACT_STRING > and similar things a useful lifetime. > Since there have already been posted solutions to each of these > that would suit me, I think it's a bit early to declare the > problem too hard and walk away. It turns out that I never stopped beating my wife because I never started. Nobody is saying that the problem is too hard and we should walk away. It's going to be a rather long time (if ever) before Scheme is sufficiently constrained in specification that all implementations will agree on the range and structure of the character type, the representation of strings, the meaning of string indexes (which relates to the range of the character type), and whether to have or how to internally handle string and vector representation. At this point in time, and for the forseeable future, an FFI will either have to try to abstract over all possible variations on those issues or pull back from them. The current proposal, if modified in the ways you and/or I have suggested, pulls back from them -- leaving gaps where only a native FFI will do. That's all I was saying. The two issues that you want to see fixed don't address any of the issues I listed. It's worth keeping in mind that we're trying to pull back a bit on some of these issues because it changes how we evaluate whether a proposal for the SRFI is a good one: if we weren't pulling back on these issues, then proposals would have to be able to expose the full glory of any particular implementation we can find or reasonably imagine; if we are pulling back on those issues, then proposals have only to provide enough mechanism for a class of bindings that we find "interesting" -- hence the suggestion of identifying some target applications that believe are typical of the common case. There's a big impedence mismatch in vector, string, and character handling between Scheme and C. People have and are actively working on implementations that are quite sophisticated in these areas -- but that don't map onto universally applicable C idioms and aren't necessarily compatible in these areas. Meanwhile, the trend in C for umpteen years has been to take simplified approaches to especially character and string processing (but also arrays). A really complete and non-limited FFI is a large-in-scope problem: it not only means making true generalizations about Scheme implementations, it also means advancing the state of the art in C programming. -t