[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: when GC is permitted
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.