> From: Jim Blandy <xxxxxx@redhat.com>

    > Tom Lord <xxxxxx@emf.net> 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