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.
On Mon, 12 Jan 2004, Thomas Bushnell, BSG wrote: > Or the horse I like to beat: for another SRFI, it always makes sense > to say "I request that you implement this", because it can always be > done, if at least by making the scheme fancier to accomodate the new > functionality. But SRFI 50 is a new thing: requesting implementation > is in many important cases, a request that the scheme in question > *dumb itself down*. I have to agree with this sentiment. And this is the major reason why I'm uncomfortable with SRFI-50 as it exists now. I feel that it locks scheme implementations into certain decisions about how to implement things, and thereby constrains the advance of the implementations in sophistication and robustness. Consider a scheme system implementor five years from now who has a SRFI-50 compliant scheme, and whose users are constantly having problems with programs that use strings as random-access data structures. S/he can make their applications run an order of magnitude faster with fewer headaches for them by implementing "ropes," but if s/he does so it will mean the implementation can no longer support SRFI-50 and code in use by an equally large population of users will break. This leaves the implementation between a rock and a hard place, as s/he cannot improve the system to the needs of some users without sacrificing its utility to other users. This sort of tradeoff happens all the time on some levels, but I think that when other choices that will work are available, we should probably avoid any choices that make such a 'Hobsons Choice' inevitable. So, my preferred form for an FFI would involve C and Scheme each keeping their hands off the others' live data. Especially don't let C functions make any assumptions about the internal representation of scheme data or the workings of the scheme Garbage Collector. Bear