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.
Tom Lord <lord@xxxxxxx> 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