Am 08 Jan 2004 14:05:27 -0500 hat Jim Blandy <xxxxxx@redhat.com> 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