[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: when GC is permitted

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 12 Jan 2004 17:03:28 -0500, Jim Blandy <jimb@xxxxxxxxxx> wrote:

felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
But, if we end up with a multitude of different SRFIs, addressing
common functionality (this reminds me of SRFI-0 vs. SRFI-7, BTW), we
have gained nothing.

I'm kind of uncomfortable with this interpretation of the SRFI
process.  I think it makes final SRFI's more preemtive of competing
ideas than is helpful to the language.

That wasn't meant in that way. There might be several implementations
providing similar functionality. But there are certain "basic"
facilities, where, when provided in too many ways, portability
actually suffers. Consider the effort wasted when porting a large
C library (like GTK+) to a single FFI SRFI - while neglecting all
implementations that support a different FFI SRFI.

It's obviously good to avoid gratuitous differences.  So a SRFI's
editors should feel obliged to address as many concerns as they can,
and help the SRFI address as wide an audience as they can.

Indeed. That's what I'm saying.

But to suggest that a SRFI should not be finalized until there is a
consensus that it's the right thing is to re-impose the same sorts of
restrictions that the SRFI process was established to work around, as
they affected the definition of the language itself.

I did never suggest such a thing. This SRFI is a special case.
It is (in it's current form) simply too ambitious, while providing
too little abstraction and portability.