Tom Lord <xxxxxx@emf.net> writes:

> I would be very happy with (A+C) and not at all with (B).  My _guess_
> is that we can get people to help make an (A+C) approach very
> successful.

I, as well as several others off list, agree with Tom on the idea of
hammering out a more portable FFI first and I am willing to give any
assistance I can in support of this effort.

Regarding "time is too short", it took almost a year to move SRFI-1
from draft status to final, and while I haven't read through much of
it's pre-finalization discussion archive, I can only imagine that
there would be at least an order of magnitude fewer issues for
extending the set of list operations available than standardizing an
interface between two (arguably) radically different languages like
Scheme and C.  I think an undertaking this complex deserves as much
attention as it needs to perfect it.

To this end, I would like to give Pika's FFI a second chance.  In my
opinion, not enough rationale has been given to reject a Pika-style
FFI -- only than syntax tastes, inexperience, and possible efficiency
problems.  I agree efficiency is an admirable goal, but I fear the
issue of additional memory references over letting the compiler store
return values in registers may be too unpredictable to use as an
excuse to a possible change that could solve many of the other
problems previously discussed in the mailing list.

If anyone agrees with this, perhaps a (very optimistic) plan of attack
could be:

  ~ Re-review Pika-style (and hopefully decide on it or a variation of
  it. :-)

  ~ Write a sample implementation of the above described FFI on top of
  S48 or SCSH's FFI (or any convenient existing implementation - I
  just chose these because the authors' background and experience).

  ~ Port a reasonable library to the new FFI.

  ~ Based on above experiences, work on a new, more abstract, and more
  portable SRFI.

I understand and appreciate the tremendous effort already put into
this SRFI by Mike and Richard and believe they are doing their best to
provide the community with the best they can.  However, issues have
been raised, they need to be resolved, and the matter of a portable C
FFI needs to be perfected or not standardized at all.  After all,
perfection defines the "spirit of the Scheme language" [1] and
properly handling a problem the first time is just one facet of that
perfection.  After all, this is what distinguishes Scheme from Common
Lisp.  :-)

-jivera

[1] Revised(5) Report on the Algorithmic Language Scheme, 6.2.3