[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pika-style from first principles

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 Tue, 13 Jan 2004 22:46:15 +0100 hat Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> geschrieben:

"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.)

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

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.