>>>>> "RK" == Richard Kelsey <xxxxxx@s48.org> writes:

RK>    (B) Address as many of the issues that have been raised as is
RK>        possible while leaving SRFI-50's style intact

RK> (B) would be my choice, especially because I think that we
RK> could now come up with a much better characterization of what
RK> SRFI-50 is and is not intended for than exists in the
RK> current draft.

As Tom pointed out, the current SRFI draft---even though it may not be
suitable "standard" material---has a few advantages.

- Many (but not all) Scheme systems can quite easily support it,
  because it already matches the FFI they have currently.

- There's lots of experience with this kind of FFI, and it's proven
  to work (for Scheme systems supporting it) for hooking up a wide
  variety of C libraries.

- There's a lot of binding code out there that uses this style of SRFI
  which could easily be changed to actually build on the SRFI and
  could thus be easily more portable (if not completely portable).

- No existing, released Scheme system I know except for the JVM-based
  ones supports a Pike-style or JNI-style FFI.

- A Pika-style or JNI-style FFI could be built on top of it, and it
  could be built in a portable manner.

This is all independent from Richard's and my willingness to write up
a more general FFI.  However, I've concluded that SRFI 50 is not the
place to do this---time's too short, and there are good reasons for
leaving this style of SRFI obviously documented.

So---while SRFI 50 may not be suitable for a "standard" of any kind,
I'd say there are some arguments in favor of keeping it in place.  The
questions are:

- Do we clean up before moving on?  (While leaving its style intact.)
  I think this can be done with a reasonable amount of effort.

- What do we give the result?  My inclination is to finalize it, with
  a clearly recognizable list of issues at the beginning.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla