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.
Am 08 Jan 2004 14:05:27 -0500 hat Jim Blandy <jimb@xxxxxxxxxx> geschrieben:
But here's the alternative. Under a SRFI-50 style interface, here's the implementation of car: scheme_value SCHEME_CAR (scheme_value pair) { return untag_pair (pair)->car; } Under most reasonable tagging systems, untag_pair can be a subtraction; the '->car' is a subsequent addition, which can be folded in with the untagging; and then the whole thing can be easily inlined, and possibly turned into an offset in the addressing mode of a load instruction. So the whole thing turns into a single instruction. There's no comparison. I think JNI entails at least one order of magnitude more instructions to implement 'car'. This is why Richard doesn't like JNI-style.
Now, I'm all for maximum performance, if possible. But that's not (IMHO) the proper goal for this SRFI. The performance side of this should come *after* it has been ensured that it is reasonable easy to write *correct* code. Since we are using C here, correctness can not be ensured completely - yet, we should try very hard to simplify the semantics of FFI code, from the user's perspective. Personally, all the syntactic issues, and how exactly gc-protection is set up, naming, etc. is rather unimportant to me. Using Scheme mainly for interfacing to foreign code is what I do most, including packaging code written by others that interfaces to external libs. I happly debug Scheme code, wether implementation-specific or portable, I grudgingly debug Scheme/FFI code specialized to one implementation. But something I'm not going to do is debugging Scheme/FFI code that conforms superficially to a (allegedly) portable API, works on some implementations and then fails on others. Unless performance-considerations on the instruction-level are important (and I doubt this is very often the case, and even if it is: just push more logic over into the C side), let's forget about this and fix the more obvious problems. cheers, felix