Email list hosting service & mailing list manager

(Previous discussion continued)
Re: Pika-style from first principles Felix Winkelmann (14 Jan 2004 06:25 UTC)

Re: Pika-style from first principles Felix Winkelmann 14 Jan 2004 06:25 UTC

Am Tue, 13 Jan 2004 22:46:15 +0100 hat Michael Sperber
<> geschrieben:

>>>>>> "felix" == felix  <> 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.