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